[Seaside] Re: Building realtime applications with Seaside
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)
> 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
>>>> 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
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside