[Seaside] Re: Building realtime applications with Seaside

[Sebastian Sastre]

what you need is keeping sessions out of smalltalk images

Redis rings a bell for that (and other things you'll need, like trans-image observer pattern)

sebastian

o/

> On 18/06/2014, at 16:17, "Esteban A. Maringolo" <emaringolo at gmail.com> wrote:
> 
> 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.
>>> 
>>> Cheers
>>> Philippe
>>> 
>> 
>> 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
> "natural".
> 
> 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
> JS.
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside