Building realtime applications with Seaside

> Hello,
>
> Has anyone used Seaside to build a realtime webapp?
>
> I realise that I could use the Zinc Websockets code, but I wanted to check whether that was an actual Seaside image - or collection of packages - that was designed to do realtime in a Seaside style?
>
> Cheers
> Andy
> ᐧ
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> <<
>
> Hi Andy,
>
> There is also Zinc-Server-Sent-Events:
>
>   http://forum.world.st/Zinc-Server-Sent-Events-td4705635.html
>
> Nothing spectacular, but it should work.
>
> Sven
>
> >>
>
> Hi Sven,
>
> I hadn't spotted that you had added SSE. That's great!
>
> So, I think my new question is how I would wire that into a Seaside application. Is there a single  listener class that can announce data changes. Or would each component somehow wire its model to the connection?
>
> My experience with Seaside is very limited, so if there is a good example/guide to this specific question, i.e. handling changes to the underlying model, please nudge me in that direction.

> On Wed, Jun 18, 2014 at 12:28 AM, Andy Burnett
> <[hidden email]> wrote:
>>
>> <<
>>
>> Hi Andy,
>>
>> There is also Zinc-Server-Sent-Events:
>>
>>  http://forum.world.st/Zinc-Server-Sent-Events-td4705635.html
>>
>> Nothing spectacular, but it should work.
>>
>> Sven
>>
>>>>
>>
>> Hi Sven,
>>
>> I hadn't spotted that you had added SSE. That's great!
>>
>> So, I think my new question is how I would wire that into a Seaside application. Is there a single  listener class that can announce data changes. Or would each component somehow wire its model to the connection?
>>
>> My experience with Seaside is very limited, so if there is a good example/guide to this specific question, i.e. handling changes to the underlying model, please nudge me in that direction.
>
> You would separate the realtime part from the normal Seaside part.
> "realtime" doesn't currently fit well into the Seaside
> request-response model and even less so in the component and session
> model. I.e there is a lock on each sessions to prevent multiple
> requests from concurrently modifying the same component.
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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.
>
> On 18 Jun 2014, at 11:15, Philippe Marschall <[hidden email]> wrote:
>
>> On Wed, Jun 18, 2014 at 12:28 AM, Andy Burnett
>> <[hidden email]> wrote:
>>>
>>> <<
>>>
>>> Hi Andy,
>>>
>>> There is also Zinc-Server-Sent-Events:
>>>
>>>  http://forum.world.st/Zinc-Server-Sent-Events-td4705635.html
>>>
>>> Nothing spectacular, but it should work.
>>>
>>> Sven

> ᐧ
> <<
> > 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?
> • 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?
> Cheers
> Andy
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> ᐧ
> <<
>>
>> > 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.

> On 18/06/2014, at 16:17, "Esteban A. Maringolo" <[hidden email]> wrote:
>
> 2014-06-18 15:11 GMT-03:00 Andy Burnett <[hidden email]>:
>>
>> ᐧ
>> <<
>>>
>>>> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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" <[hidden email]> wrote:
>>
>> 2014-06-18 15:11 GMT-03:00 Andy Burnett <[hidden email]>:
>>>
>>> ᐧ
>>> <<
>>>>
>>>>> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> On 18/06/2014, at 20:27, "Esteban A. Maringolo" <[hidden email]> 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 <[hidden email]>:
>> 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" <[hidden email]> wrote:
>>>
>>> 2014-06-18 15:11 GMT-03:00 Andy Burnett <[hidden email]>:
>>>>
>>>> ᐧ
>>>> <<
>>>>>
>>>>>> 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
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> ᐧ
> <<
>>
>> > 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.