Cross Platform Programming Languages
evan_lsa at internode.on.net
Wed Jan 17 10:08:46 CST 2007
David Lloyd wrote:
My needs are simple as am I.
Due to the nature of the intended application it is unlikely there will
be too much I will be relying on blocking transactions as required.
But to speed things up it client A will always be appending to a queue
and client B will empty it it may need a state setup of sorts but the
polling aspect is a preferred approach to replication or threaded
postings from client A to client B.
Client A need never know client B exists it simply appends transactions
to it's own DB which will be an SQL server of some form.
To complicate things Client B will have to be a Win32 box and clients
a1..an any flavour of linux I choose.
I am spoilt with Vb and .NET and Sql Server and TBH if I can't get the
same functionality out of open source approach I simply wont use it.
cat, look pigeons
>> If you can get over the fact that it's not free, and it's basic,
>> consider Real Basic (the Linux standard edition is free apparently).
> RealBasic uses an object oriented version of BASIC not unlike Visual
> Basic (at least in VB 6.X days). Its OS X GUI is very easy to use and
> its debugger is highly effective. It's not too rare that a developer
> will be able to answer your questions if something goes wrong.
>> I had a bit of a play with it last year (on Linux and Windows) and
>> they also have a MAC version as well, and the code is generally
> RealBasic is a Mac product. Because it runs atop its own virtual
> machine, it's able to port to other operating systems as you have
> found out.
>> In fact from speaking to their CEO you can actually
>> deploy to other platforms from a single "professional edition" version
>> of the product.
> Here is the crux of the matter. The core material, developed by Real
> Software, is truly cross platform. However, as Real Software isn't the
> largest software developer not all things one might require are an
> official part of RealBasic.
> I probably should say that I've had extensive experience working with
> a Real Basic POS application which initially communicated via a
> "proprietary" API to a PHP backend. Realising that the communication
> was becoming cumbersome, we took a slight digression:
> 1. I implemented a Perl SOAP server
> 2. The other person used RealBasic's SOAP plugin/libraries
> 3. ...and threads
> Here is where trouble started.
> Firstly, the virtual machine that RB uses is like the old Windows 3.1
> scheduler. It's co-operative; it cannot be preempted. In order to hide
> the delays caused by the SOAP method calls, we put the SOAP calls into
> a n RB thread and then called it in the thread.
> But the threads run on the RB virtual machine and they can't be
> preempted. So, the SOAP thread would land on the RB virtual machine
> and would sit and wait for the SOAP server. Of course, the GUI thread
> would get blocked and suddenly the application would appear to freeze.
> This got to be a total pain. We took another path. RB would write to
> an SQLITE backend and a Perl client would read from the local database
> and send the messages via SOAP to the server. This proved to be a
> winner, or so we thought...
> At some stage we noticed that messages were mysteriously dropped. We
> couldn't quite work out what it was except we knew that it would
> happen if I set the Perl SOAP client to send data too fast.
> I came to the conclusion that it wasn't the Perl stuff alone. I could
> put that on four different machines and run it as fast as Perl would
> loop it all at once and the Perl client/server would stay in sync.
> We discovered that RealBasic doesn't implement non-blocking writes to
> SQLITE3. Perl, on the other hand, would grab a lock on the database
> while it was writing to it as it was possible that RB and Perl could
> clash with each other...and we discovered that if the Perl client was
> accessing the SQLITE3 database at the same time as the RB client, then
> the Perl client would take precedence and the RB client would do
> "random stuff".
> "Random stuff" usually equated to dropping whatever statement it was
> doing, but occasionally it would corrupt the SQLITE3 file.
> Whilst we looked and asked, we came up with no sensible answer to this
> dilemma. As far as I currently know, RB will always do a blocking read
> if it's trying to access a database that is locked for some reason and
> that this block will also have the same effect as blocking the
> non-preempitble scheduler.
> I think I would still recommend RealBasic but only with careful
> investigation as to:
> a) Its handling of databases, transactions and locks
> b) Its handling of threads
> c) Its handling of SOAP / XML-RPC if you plan to use it
> To be useful in the application I suspect Evan wants it to be, you
> need to be able to do have a virtual machine where you can't block the
> GUI from doing things.
> At best you'll look unprofessional - at worst you'll get a hung
More information about the linuxsa