[Gambas-devel] for future gambas development

[Rob Kudla]

On Sun August 20 2006 06:49, Benoit Minisini wrote:
> Then the big problem is how to define the interface *and* the
> code in Gambas, and see it in the browser with this toolkit. I
> see no solution at the moment.

I have some ideas about this, and if no one has started their own 
project by the time I'm done with this huge consulting gig (mid 
to late fall) I am going to do it myself.

Basically, what you said is accurate.... the interface elements 
in the browser would just send XmlHttpRequests back to the 
server to trigger the Gambas event code.  This would include 
timer objects, which would just be implemented in Javascript but 
work the same as the interface elements.

As for how to generate events on the server that affect the 
interface, that's a problem with all Ajax toolkits, not just a 
Gambas-based one.  It'll have to be an option that the developer 
can set, but ultimately I'm afraid it's going to come down to 
polling.  

> In other words, the event loop must be completely managed by
> the browser.

That's the way with any client/server application.... the client 
manages the event loop.  But that's not so different than what 
we have now, where Qt or Gtk manages the event loop and waits 
for input from the UI.  Instead of getting X events we'll be 
getting network events.

> Maybe by taking their code, and modifying it deeply? It is an
> huge job...

I don't think we should try to tack on someone else's toolkit.  
Most of the magic here is going to be done by generating 
Javascript and sending it to the browser along with HTML or XML 
and CSS files representing the interface (which I am already 
doing with Gambas forms right now in an existing (huge) Ajax 
project, but using Perl as my CGI language and doing far more 
processing on the Javascript side) and I think for the sake of 
performance and maintainability we should maintain the ability 
to tune our view and controller code.

> Another point: their toolkit is rather slow on my Firefox, but
> I think we cannot do anything about that. Thanks to AJAX, now
> we will need an AthlonX2 to browse the web :-)

I've run into this too, and it's pretty frustrating.  I imagine 
the next browser arms race is going to be "who can make 
Javascript and async communications the fastest".

Rob