Aida with Realtime (WebSockets) support released

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

Aida with Realtime (WebSockets) support released

Janko Mivšek
Dear Smalltalkers,

I think it can be safely claimed that Aida/Web is a first Smalltalk web
framework, even more, one of the first frameworks at all to integrate
HTML5 WebSockets for so called realtime web apps. Realtime in sense that
values on the page are updated immediately when value changes on the
server, without needing to manually reload a page.

You can see that in action from WebSocket-capable browsers (latest
Firefox and Chrome) if you open in two browsers the online Aida realtime
counter demo, click buttons on one and observe changes instantly in both
browsers:

        http://demo.aidaweb.si/demos?view=realtime

And how easy is using real-time in your code? See the simplified code of
above demo:

  WebDemoApp>>viewRealtime

    | e counterElement |

    self enableRealtime.

    counterElement := e add: self counterElement.

    (e addButtonText: ' Decrement ')
        noSubmit;
        onClickDo: [self observee decCounter].
    (e addButtonText: ' Increment ')
        noSubmit;
        onClickDo: [self observee incCounter].

    self observee
        onChangeDo: [counterElement update]
        on: counterElement app: self.

    self add: e.

  WebDemoApp>>counterElement

    | e |
    e := WebElement newSpan.
    e style: 'font-size: 40px'.
    e addText: self observee counter printString.
   ^e

To describe this code a bit: you first enable realtime for this view of
demo App. Element on the webpage to update in realtime must be created
in a separate method (#counterElement). After buttons for increment and
decrement we come to the main part - registering the block to execute on
every change of domain object. Calling simply #update to the counter
element is enough to be updated on all browsers which currently observe
that counter demo.

How this works? Behind the scenes a so called realtime channel is open
between browser and Aida server. This WebSocket based channel is
bidirectional and full-duplex, meaning that Aida can send back to the
browser a message at any time. In above case a command to update the
counter element is sent back to all browsers immediately after counter
is changed.

New Aida 6.5 Interim release is released for Squeak, Pharo and
VisualWorks and available from usual places. See http://www.aidaweb.si
for more.

Everyone is welcome to try it and come with suggestions how to use this
new feature, how to improve it, ....

Further read:

   http://www.aidaweb.si/websocket%20support
   http://www.swazoo.org/websocket

Best regards
Janko


--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Re: Aida with Realtime (WebSockets) support released

David T. Lewis
On Thu, Nov 01, 2012 at 08:36:35PM +0100, Janko Miv??ek wrote:
> Dear Smalltalkers,
>
> I think it can be safely claimed that Aida/Web is a first Smalltalk web
> framework, even more, one of the first frameworks at all to integrate
> HTML5 WebSockets for so called realtime web apps. Realtime in sense that
> values on the page are updated immediately when value changes on the
> server, without needing to manually reload a page.

I'm afraid that I have not been keeping up with web application development,
but this sounds really interesting. I have worked with automotive manufacturing
for many years, and being able to do real time displays like you describe
here could be a real game changer.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Aida with Realtime (WebSockets) support released

Janko Mivšek
Dne 01. 11. 2012 21:52, piše David T. Lewis:
> On Thu, Nov 01, 2012 at 08:36:35PM +0100, Janko Miv??ek wrote:

>> I think it can be safely claimed that Aida/Web is a first Smalltalk web
>> framework, even more, one of the first frameworks at all to integrate
>> HTML5 WebSockets for so called realtime web apps. Realtime in sense that
>> values on the page are updated immediately when value changes on the
>> server, without needing to manually reload a page.

> I'm afraid that I have not been keeping up with web application development,
> but this sounds really interesting. I have worked with automotive manufacturing
> for many years, and being able to do real time displays like you describe
> here could be a real game changer.

I actually need realtime web app support for something similar: to
notify about some discrepancies on gas pipeline like some flowmeter
overloaded, malfunction of some equipment, some other urgent situation
etc. Those notifications will be shown on otherwise normal web app which
is open all the time at the user desktops, because it is used daily for
other tasks.

See also a similar GSoC project by Rustem Khubbatov:

  HMI (Human-Machine Interface) with Amber
  http://gsoc2012.esug.org/projects/mmi-amber
  https://dl.dropbox.com/u/792245/GSoC-HMI_with_Amber.mp4

Best regards
Janko

--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Re: Aida with Realtime (WebSockets) support released

David T. Lewis
On Thu, Nov 01, 2012 at 10:53:03PM +0100, Janko Miv??ek wrote:

> Dne 01. 11. 2012 21:52, pi??e David T. Lewis:
> > On Thu, Nov 01, 2012 at 08:36:35PM +0100, Janko Miv??ek wrote:
>
> >> I think it can be safely claimed that Aida/Web is a first Smalltalk web
> >> framework, even more, one of the first frameworks at all to integrate
> >> HTML5 WebSockets for so called realtime web apps. Realtime in sense that
> >> values on the page are updated immediately when value changes on the
> >> server, without needing to manually reload a page.
>
> > I'm afraid that I have not been keeping up with web application development,
> > but this sounds really interesting. I have worked with automotive manufacturing
> > for many years, and being able to do real time displays like you describe
> > here could be a real game changer.
>
> I actually need realtime web app support for something similar: to
> notify about some discrepancies on gas pipeline like some flowmeter
> overloaded, malfunction of some equipment, some other urgent situation
> etc. Those notifications will be shown on otherwise normal web app which
> is open all the time at the user desktops, because it is used daily for
> other tasks.

Yes, that's the idea exactly. I think I need to educate myself about Aida :)


> See also a similar GSoC project by Rustem Khubbatov:
>
>   HMI (Human-Machine Interface) with Amber
>   http://gsoc2012.esug.org/projects/mmi-amber
>   https://dl.dropbox.com/u/792245/GSoC-HMI_with_Amber.mp4
>

Very interesting stuff. Thanks for these links also.

Dave


Reply | Threaded
Open this post in threaded view
|

Test failures in Chronology

David T. Lewis
In reply to this post by Janko Mivšek
We have two test failures related to time zone offset handling:

  TimeStampTest>>testFromSeconds
  TimeStampTest>>testReadFromA1

In #testFromSeconds, we compare a TimeStamp created from an integer seconds
to another TimeStamp created from strings. They are intended to refer to
the "same" time stamp, but one has a time zone offset and the other has
the offset set to zero (UTC), more or less like this:

  tsFromStrings := TimeStamp date: ('1-10-2000' asDate) time: ('11:55:00 am' asTime).
  tsFromStrings. ==> 10 January 2000 11:55 am
  tsFromStrings offset. ==> 0:00:00:00

  tsFromIntegerSeconds := TimeStamp fromSeconds: 3124958100.
  tsFromIntegerSeconds. ==> 10 January 2000 11:55 am
  tsFromIntegerSeconds offset. ==> 0:01:00:00

I believe that the discrepancy is related to the change we did in trunk here:

  Name: Kernel-cmm.671
  Author: cmm
  Time: 10 February 2012, 4:58:49.106 pm
 
  Decided against the localized vs. globalized mode.  Timespans created in
  the context of an offset will start in that offset.  When no context is
  available, the defaultOffset for Timespans must be zero.  For example,
  two ways to make a Date for today:
     Date today.  'start is midnight at offset zero.  Will compare
     successfully to other Date today results.'
 
     DateAndTime now asDate.  'In this case, the start is midnight of the
     local time-zone.  It can only compare equally to Dates of its time-zone.'

I am not sure how this should be handled. Chris, can you comment?

Thanks,
Dave


Reply | Threaded
Open this post in threaded view
|

Re: Test failures in Chronology

Chris Muller-3
I see you already committed a patch.  TimeStamp will be going away in 4.5.

 - Chris



On Sun, Nov 4, 2012 at 8:55 AM, David T. Lewis <[hidden email]> wrote:

> We have two test failures related to time zone offset handling:
>
>   TimeStampTest>>testFromSeconds
>   TimeStampTest>>testReadFromA1
>
> In #testFromSeconds, we compare a TimeStamp created from an integer seconds
> to another TimeStamp created from strings. They are intended to refer to
> the "same" time stamp, but one has a time zone offset and the other has
> the offset set to zero (UTC), more or less like this:
>
>   tsFromStrings := TimeStamp date: ('1-10-2000' asDate) time: ('11:55:00 am' asTime).
>   tsFromStrings. ==> 10 January 2000 11:55 am
>   tsFromStrings offset. ==> 0:00:00:00
>
>   tsFromIntegerSeconds := TimeStamp fromSeconds: 3124958100.
>   tsFromIntegerSeconds. ==> 10 January 2000 11:55 am
>   tsFromIntegerSeconds offset. ==> 0:01:00:00
>
> I believe that the discrepancy is related to the change we did in trunk here:
>
>   Name: Kernel-cmm.671
>   Author: cmm
>   Time: 10 February 2012, 4:58:49.106 pm
>
>   Decided against the localized vs. globalized mode.  Timespans created in
>   the context of an offset will start in that offset.  When no context is
>   available, the defaultOffset for Timespans must be zero.  For example,
>   two ways to make a Date for today:
>      Date today.  'start is midnight at offset zero.  Will compare
>      successfully to other Date today results.'
>
>      DateAndTime now asDate.  'In this case, the start is midnight of the
>      local time-zone.  It can only compare equally to Dates of its time-zone.'
>
> I am not sure how this should be handled. Chris, can you comment?
>
> Thanks,
> Dave
>
>