[Seaside] Re: Building realtime applications with Seaside

[Sebastian Sastre]

sure, seaside is not the tool for realtime

sebastian

o/

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