[Seaside] Re: Building realtime applications with Seaside
Sebastian Sastre
sebastian at flowingconcept.com
Wed Jun 18 22:07:05 UTC 2014
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
More information about the seaside
mailing list