[Seaside] Re: Building realtime applications with Seaside
Esteban A. Maringolo
emaringolo at gmail.com
Wed Jun 18 19:17:26 UTC 2014
2014-06-18 15:11 GMT-03:00 Andy Burnett <andy.burnett at knowinnovation.com>:
>> > I believe (if I remember correctly), that the app (vaguely) described here
>> > http://forum.world.st/Another-Pharo-based-solution-released-td4762341.html
>> > is also using web sockets. But you should ask.
>> > It is perfectly possible to combine Seaside with other servers/services in the same or different images. But this is a broad subject.
>> Correct. Implement the real time part in Zinc and let the other things
>> go through to the Seaside adapter.
> Thanks guys. I want to be absolutely clear about your advice - partly for my benefit, but also for people who might search for these answers.
> If we take the example of creating a real time things to do list.
> Seaside could be appropriate for creating e.g. the login system, account management, reporting etc. Basically, anything that doesn't need to be updated in real time, and shared between users synchronously
> The real time components would be handled by Zinc, and integrated into the overall application.
> If I have got that right, this poses some other questions:
> How does one handle session management and authentication between the two elements. For example. I login to the Seaside session on port 80, and navigate to the real time url. Let's assume Zinc is running on port 3000. Is there any - built-in - way for the Zinc server to know that I am authenticated already? Or, do I have to roll my own approach?
This is the main reason I desisted using this mixed approach. It isn't
You have to roll out your own way of getting back the Seaside session
or authentication. It is... if you're using Zinc delegates (other than
the Seaside adapter) the session management of Seaside happens
"upstream" in the flow, so Zinc isn't aware of anything related with
the session, so before responding you should lookup the session
somewhere (based on the session tracking choosen for Seaside, being it
cookies or _s parameter) and then proceed with the request.
If you have more than one "worker image" attending web requests, the
websockets image must be the same as the Seaside image if you want to
find the seaside session... and you get the picture of how convoluted
this can turn out to be.
Being stateful is good... until it's not anymore :)
> What do you recommend on the client side for listening to the changes. I know that Nico built some classes that link Amber with Pharo, but I don't know if they help on the real time side. Sven, what have you used?
The Tasks example Sven posted is a case of using Amber to connect to
the ws:// and listen for its events. In my case I used it directly in
More information about the seaside