[Seaside] Re: Building realtime applications with Seaside

[Esteban A. Maringolo]

I know, you can user Redis, Riak or memcache, but the thing is Seaside
is not meant to be used that way. It is stateful from the ground up,
not only for session data. Only gemstone can serialize sessions and
attend requests for the same session using different gems.

That's why my "dream" is to have everything restful based only on Zinc
server and a few extra things, and move all the UI to the client. But
that's a long route ahead I have.


Esteban A. Maringolo


2014-06-18 19:07 GMT-03:00 Sebastian Sastre <sebastian at flowingconcept.com>:
> 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
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside