Building realtime applications with Seaside

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Building realtime applications with Seaside

Andy Burnett
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
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Sven Van Caekenberghe-2
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

On 17 Jun 2014, at 18:11, Andy Burnett <[hidden email]> wrote:

> 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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Andy Burnett
In reply to this post by Andy Burnett
<<
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.

Cheers
Andy

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Sven Van Caekenberghe-2
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
>>
>>>>
>>
>> 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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Philippe Marschall
On Wed, Jun 18, 2014 at 11:30 AM, Sven Van Caekenberghe <[hidden email]> wrote:
> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Esteban A. Maringolo
In reply to this post by Sven Van Caekenberghe-2
Hi Andy,

I used Zinc's websockets to push data to a javascript "client", that
updated info on a map every time an event was received from a mobile
device.

However, after analyzing the real usage of such feature (low), it's
maintenance became complex (the mix of js, seaside and ws), so I
switched from a push (websocket) to a pull (ajax) refresh, that let me
implement everything in "standard" Seaside flow (except for a minimum
JS part), but also helped me to have less state in the js client.

There is no official web of doing real-time with Seaside as far as I
know. And with web apps becoming more JS and RESTful based, sometimes
it's not easy to integrate Seaside in such workflow. Not even thinking
about integrating something like http://socket.io

However if you need help, I'll be happy to help you as much as I can.

Regards!

Esteban A. Maringolo


2014-06-18 6:30 GMT-03:00 Sven Van Caekenberghe <[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.
>
> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Andy Burnett
In reply to this post by Andy Burnett
<< 
> 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.
  1. 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
  2. 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:
  1. 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?
  2. 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
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Sven Van Caekenberghe-2
Andy,

Now that you mention a todo list as an example, I suddenly remembered this stuff by Sebastian Sastre:

A tour into tasks, a flowing experiment on full-duplex web applications using web sockets
http://blog.flowingconcept.com/brandIt/a-tour-into-tasks-a-flowing-experiment-on-fullduplex-web-applications-using-web-sockets

Is a ~28m screencast I’ve published in enGrish giving a tour on various details of this little experiment:

http://tasks.flowingconcept.com/service/

Really cool stuff using Pharo and much more...

On 18 Jun 2014, at 20:11, Andy Burnett <[hidden email]> wrote:

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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Esteban A. Maringolo
In reply to this post by Andy Burnett
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
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

sebastianconcept@gmail.co
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
Reply | Threaded
Open this post in threaded view
|

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 <[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
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

sebastianconcept@gmail.co
sure, seaside is not the tool for realtime

sebastian

o/

> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Building realtime applications with Seaside

Philippe Marschall
In reply to this post by Andy Burnett
On Wed, Jun 18, 2014 at 8:11 PM, Andy Burnett
<[hidden email]> wrote:

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

Correct.

> 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?

I would run both on the same port. Remember Seaside is not a web
server, Zinc is. Zinc does it's thing first and the delegates to
Seaside. For the real time parts you would simply implement them in
Zinc an then not delegate to seaside.
I would try to avoid dependencies on seaside sessions from the
realtime part. Instead I would depend only on domain objects. You may
need a "message bus" between the parts.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building realtime applications with Seaside

Andy Burnett
In reply to this post by Andy Burnett
<<<
On Wed, Jun 18, 2014 at 8:11 PM, Andy Burnett
<[hidden email]> wrote:
>
> ᐧ
> <<
>>
>> > 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.

Correct.

> 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?

I would run both on the same port. Remember Seaside is not a web
server, Zinc is. Zinc does it's thing first and the delegates to
Seaside. For the real time parts you would simply implement them in
Zinc an then not delegate to seaside.
I would try to avoid dependencies on seaside sessions from the
realtime part. Instead I would depend only on domain objects. You may
need a "message bus" between the parts.

Cheers
Philippe
>>>


Thanks everyone.

Philippe, I hadn't quite understood the relationship between Zinc and Seaside, so that is a useful observation. I might try splitting things the way you suggest.

Cheers
Andy 

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside