[Gambas-devel] for future gambas development

[José L. Redrejo Rodríguez]

El lun, 21-08-2006 a las 17:01 +0200, Benoit Minisini escribió:
> On Monday 21 August 2006 00:29, Rob Kudla wrote:
> > 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
> >
> 
> Javascript/HTML generated interface should send events to the Gambas 
> application by using XmlHttpRequest, that's ok.
> 
> Now maybe the Gambas application could answer by sending an updated DOM model 
> of the page. This way, reloading the entire page is avoided.
> 
> After all, the gambas application generated the current page, so maybe it 
> could keep its state, and then could send the difference between the old one 
> and the new one to the browser?
> 

This is exactly what comet does, but adding another feature: it pushes
the updates to all the browsers that are connected to that url. It's
what google uses with its chat in gmail.


> I don't know how this could be implemented in JavaScript: updating the DOM 
> model of the current page from a file describing the differences.
>