Hi,

Everybody think happy thoughts, flowers, waterfalls, idle servers :-)

On Wed, Jul 16, 2008 at 11:34 AM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 10:33 AM, Daan van Etten <[EMAIL PROTECTED]> wrote:
>> In my opinion it depends on your use case, but in high-load environments I'd
>> suggest to keep the state at the client.
>
> As long as you have 1 page that uses the server as an RPC service,
> this works.

Yes, and that's a (non-)web programming model some of us are
considering currently.
I would summarise the principle as "RESTful service, stateful GUI",
the former being 100% server-side, the later being 100% browser-side.
I said non-web model because it uses the browser not as a web browser
but as a platform to download and execute the stateful client. Some of
that state might be made bookmarkable with some tricks, but that's
probably just a way to pass initial parameters to the client, ignored
by the (static) server.

At the risk of getting increasingly off topic, I'd like to continue
this discussion for the off chance of inspiring somebody to extend the
wicket AJAX functionality in this direction (of which I have very
little understanding currently).

I for example been looking to broaden our web GUI development skill
portfolio (currently wicket only :-) ) by experimenting with something
more "rapid". Sometimes I just don't need an elaborate,
server-controlled application, just some JS-heavy HTML kicking around
simple web services which already exist or I have to provide anyway.
I'm about to plunge into GWT, hoping to replace its built-in
server-side components, XML-RPC and serialization mechanism with
external JSON-encoded REST services if possible. (Same Origin Policy
is one obstacle, authentication is another...)

So assuming this works (and it does seem to work similarly in GMail
which I right now use to compose this message along with possibly
hundreds of thousands of others at the same time), can wicket be
extended with this principle? Wicket could work as it does now as
fallback and for the parts of the application that fit the wicket
model better, but have some of its AJAX callbacks "outsourced" to pure
data services. The fallback could call the same or a more direct
(trusted or an EJB even) service from the server side.

Oh well, just a thought.


Gabor Szokoli

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to