Cross Platform Programming Languages

Evan evan_lsa at internode.on.net
Wed Jan 17 10:08:46 CST 2007


David Lloyd wrote:
Tim, David
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

evan
> Tim,
>
>> 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
>> cross-platform.
>
> 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. 
> However...
>
> 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 
> application.
>
>
> DSL



More information about the linuxsa mailing list