GUIs - ruby on rails, rico

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Joe Armstrong (AL/EAB)

It's even better than I thought. The Canvas widget *is* in
Firefox 1.5 beta 1 and runs out of the box!!!

Strangely there are very few working examples on the net to show how the
canvas is used.

This is amazing - up to now it has been difficult to direct display vector graphics
on the web - with the canvas widget this is easy.

Wow

/Joe




> -----Original Message-----
> From: owner-erlang-questions
> [mailto:owner-erlang-questions]On Behalf Of Joe Armstrong
> (AL/EAB)
> Sent: den 19 september 2005 11:22
> To: erlang-questions
> Subject: GUIs - ruby on rails, rico
>
>
>
> It seems like my quest for a GUI is almost over.
>
> Klacke had pointed me at XMLHTTP but I just didn't get it (dumbo) -
>
> Then I hacked a bit and - WOW. Firstly XMLHTTP is nothing
> about XML - it's just allows
> a light weight RPC to made from within a web page. So you
> connect a bit
> of JavaScript to an event - this JavaScript RPCs a server,
> the server replies with
> a string that the JavaScript interprets (any old string - not
> necessarily XML)
> and the JavaScript modifies the web page.
>
> The last bit (the JavaScript modifies the web page) is the
> tricky bit - to
> do this you need to use the DOM - which is (uuugh) painful.
>
> Fortunately there are libraries to do this - ruby on rails
> uses prototype.js to do this
> http://prototype.conio.net/ And Tobbe has written a library
> (jungerl/lib/js) to take to prototype.js
>
> Also of interest is rico http://openrico.org/rico/home.page 
> (especially their innerHTML
> demo) (see
> http://openrico.org/rico/demos.page?demo=ricoAjaxInnerHTML.html)
>
> As far as I can see one could make a pretty snazzy GUI in a
> web brower with
>
> - a local HTTP server (yaws)
> - XMLHTTP and
> - rico or prototype.js
>
> Also in the pipeline is an HTML extension <canvas> which has
> made it to
> safari and mozilla - this is looking good.
>
> What would be even nicer would be a port of the konfabulator to linux
> http://www.konfabulator.com/ - since this (I think) would
> solve all my GUI problems.
>
> This technology is about to explode - so yaws should be well placed -
> this means that servers are going to be handling a lot of
> lightweight RPCs
>
> So go hack
>
> /Joe
>
>


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

bryan rasmussen-2
If you're talking about what I think, the Canvas as an editable vector
graphics area is part of the whatwg specifications
http://www.whatwg.org/specs/web-apps/current-work/

whatwg has various browser manufacturers/implementors as part of their
group, but not IE.
It has not been finalized in their specs yet IIRC thus given this I am
not surprised as to the lack of examples as yet.

On 9/19/05, Joe Armstrong (AL/EAB) <joe.armstrong> wrote:

>
> It's even better than I thought. The Canvas widget *is* in
> Firefox 1.5 beta 1 and runs out of the box!!!
>
> Strangely there are very few working examples on the net to show how the
> canvas is used.
>
> This is amazing - up to now it has been difficult to direct display vector graphics
> on the web - with the canvas widget this is easy.
>
> Wow
>
> /Joe
>
>
>
>
> > -----Original Message-----
> > From: owner-erlang-questions
> > [mailto:owner-erlang-questions]On Behalf Of Joe Armstrong
> > (AL/EAB)
> > Sent: den 19 september 2005 11:22
> > To: erlang-questions
> > Subject: GUIs - ruby on rails, rico
> >
> >
> >
> > It seems like my quest for a GUI is almost over.
> >
> > Klacke had pointed me at XMLHTTP but I just didn't get it (dumbo) -
> >
> > Then I hacked a bit and - WOW. Firstly XMLHTTP is nothing
> > about XML - it's just allows
> > a light weight RPC to made from within a web page. So you
> > connect a bit
> > of JavaScript to an event - this JavaScript RPCs a server,
> > the server replies with
> > a string that the JavaScript interprets (any old string - not
> > necessarily XML)
> > and the JavaScript modifies the web page.
> >
> > The last bit (the JavaScript modifies the web page) is the
> > tricky bit - to
> > do this you need to use the DOM - which is (uuugh) painful.
> >
> > Fortunately there are libraries to do this - ruby on rails
> > uses prototype.js to do this
> > http://prototype.conio.net/ And Tobbe has written a library
> > (jungerl/lib/js) to take to prototype.js
> >
> > Also of interest is rico http://openrico.org/rico/home.page
> > (especially their innerHTML
> > demo) (see
> > http://openrico.org/rico/demos.page?demo=ricoAjaxInnerHTML.html)
> >
> > As far as I can see one could make a pretty snazzy GUI in a
> > web brower with
> >
> >       - a local HTTP server (yaws)
> >       - XMLHTTP and
> >       - rico or prototype.js
> >
> > Also in the pipeline is an HTML extension <canvas> which has
> > made it to
> > safari and mozilla - this is looking good.
> >
> > What would be even nicer would be a port of the konfabulator to linux
> > http://www.konfabulator.com/ - since this (I think) would
> > solve all my GUI problems.
> >
> > This technology is about to explode - so yaws should be well placed -
> > this means that servers are going to be handling a lot of
> > lightweight RPCs
> >
> > So go hack
> >
> > /Joe
> >
> >
>


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

bryan rasmussen-2
given that the upcoming builds of firefox/mozilla should also be SVG
capable I would suppose that SVG will be the better overall platform
for doing it. I have seen a demo of svg inside canvas and canvas
inside xhmtl inside svg etc. running in a private mozilla build. was
pretty impressive.

On 9/19/05, bryan rasmussen <rasmussen.bryan> wrote:

> If you're talking about what I think, the Canvas as an editable vector
> graphics area is part of the whatwg specifications
> http://www.whatwg.org/specs/web-apps/current-work/
>
> whatwg has various browser manufacturers/implementors as part of their
> group, but not IE.
> It has not been finalized in their specs yet IIRC thus given this I am
> not surprised as to the lack of examples as yet.
>
> On 9/19/05, Joe Armstrong (AL/EAB) <joe.armstrong> wrote:
> >
> > It's even better than I thought. The Canvas widget *is* in
> > Firefox 1.5 beta 1 and runs out of the box!!!
> >
> > Strangely there are very few working examples on the net to show how the
> > canvas is used.
> >
> > This is amazing - up to now it has been difficult to direct display vector graphics
> > on the web - with the canvas widget this is easy.
> >
> > Wow
> >
> > /Joe
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-erlang-questions
> > > [mailto:owner-erlang-questions]On Behalf Of Joe Armstrong
> > > (AL/EAB)
> > > Sent: den 19 september 2005 11:22
> > > To: erlang-questions
> > > Subject: GUIs - ruby on rails, rico
> > >
> > >
> > >
> > > It seems like my quest for a GUI is almost over.
> > >
> > > Klacke had pointed me at XMLHTTP but I just didn't get it (dumbo) -
> > >
> > > Then I hacked a bit and - WOW. Firstly XMLHTTP is nothing
> > > about XML - it's just allows
> > > a light weight RPC to made from within a web page. So you
> > > connect a bit
> > > of JavaScript to an event - this JavaScript RPCs a server,
> > > the server replies with
> > > a string that the JavaScript interprets (any old string - not
> > > necessarily XML)
> > > and the JavaScript modifies the web page.
> > >
> > > The last bit (the JavaScript modifies the web page) is the
> > > tricky bit - to
> > > do this you need to use the DOM - which is (uuugh) painful.
> > >
> > > Fortunately there are libraries to do this - ruby on rails
> > > uses prototype.js to do this
> > > http://prototype.conio.net/ And Tobbe has written a library
> > > (jungerl/lib/js) to take to prototype.js
> > >
> > > Also of interest is rico http://openrico.org/rico/home.page
> > > (especially their innerHTML
> > > demo) (see
> > > http://openrico.org/rico/demos.page?demo=ricoAjaxInnerHTML.html)
> > >
> > > As far as I can see one could make a pretty snazzy GUI in a
> > > web brower with
> > >
> > >       - a local HTTP server (yaws)
> > >       - XMLHTTP and
> > >       - rico or prototype.js
> > >
> > > Also in the pipeline is an HTML extension <canvas> which has
> > > made it to
> > > safari and mozilla - this is looking good.
> > >
> > > What would be even nicer would be a port of the konfabulator to linux
> > > http://www.konfabulator.com/ - since this (I think) would
> > > solve all my GUI problems.
> > >
> > > This technology is about to explode - so yaws should be well placed -
> > > this means that servers are going to be handling a lot of
> > > lightweight RPCs
> > >
> > > So go hack
> > >
> > > /Joe
> > >
> > >
> >
>


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Martin Carlson-2
In reply to this post by Joe Armstrong (AL/EAB)

Hi all,

I haven't had a close look at this XMLHTTP, but to me it
don't sound to far from XUL (http://www.xulplanet.com).
Where you use the mozilla chrome engine to render a gui.
The "thing" is that you can either render XUL pages
(much like html pages) remotely in a sandbox mode or
you can install them ontop of mozilla as a extention,
which infact run as a "normal" application i.e. thunderbird
or firefox.

The XUL rendering works in pretty much the same way where
you have a horrible XML file and thus a DOM tree that you can
manipulat with java scripts. Thus, using the XmlHttpRequest to
communicate with the server can make the gui appear interactive
where all communication takes place in the background as POST and
GET requests to the server.

Martin

On Mon, 19 Sep 2005, Joe Armstrong (AL/EAB) wrote:

>
> It's even better than I thought. The Canvas widget *is* in
> Firefox 1.5 beta 1 and runs out of the box!!!
>
> Strangely there are very few working examples on the net to show how the
> canvas is used.
>
> This is amazing - up to now it has been difficult to direct display vector graphics
> on the web - with the canvas widget this is easy.
>
> Wow
>
> /Joe
>
>
>
>
>> -----Original Message-----
>> From: owner-erlang-questions
>> [mailto:owner-erlang-questions]On Behalf Of Joe Armstrong
>> (AL/EAB)
>> Sent: den 19 september 2005 11:22
>> To: erlang-questions
>> Subject: GUIs - ruby on rails, rico
>>
>>
>>
>> It seems like my quest for a GUI is almost over.
>>
>> Klacke had pointed me at XMLHTTP but I just didn't get it (dumbo) -
>>
>> Then I hacked a bit and - WOW. Firstly XMLHTTP is nothing
>> about XML - it's just allows
>> a light weight RPC to made from within a web page. So you
>> connect a bit
>> of JavaScript to an event - this JavaScript RPCs a server,
>> the server replies with
>> a string that the JavaScript interprets (any old string - not
>> necessarily XML)
>> and the JavaScript modifies the web page.
>>
>> The last bit (the JavaScript modifies the web page) is the
>> tricky bit - to
>> do this you need to use the DOM - which is (uuugh) painful.
>>
>> Fortunately there are libraries to do this - ruby on rails
>> uses prototype.js to do this
>> http://prototype.conio.net/ And Tobbe has written a library
>> (jungerl/lib/js) to take to prototype.js
>>
>> Also of interest is rico http://openrico.org/rico/home.page
>> (especially their innerHTML
>> demo) (see
>> http://openrico.org/rico/demos.page?demo=ricoAjaxInnerHTML.html)
>>
>> As far as I can see one could make a pretty snazzy GUI in a
>> web brower with
>>
>> - a local HTTP server (yaws)
>> - XMLHTTP and
>> - rico or prototype.js
>>
>> Also in the pipeline is an HTML extension <canvas> which has
>> made it to
>> safari and mozilla - this is looking good.
>>
>> What would be even nicer would be a port of the konfabulator to linux
>> http://www.konfabulator.com/ - since this (I think) would
>> solve all my GUI problems.
>>
>> This technology is about to explode - so yaws should be well placed -
>> this means that servers are going to be handling a lot of
>> lightweight RPCs
>>
>> So go hack
>>
>> /Joe
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

bryan rasmussen-2
xmlhttp is an object included with most modern browsers which allows a
scripting engine implemented in the browser to make asynchronous http
gets, posts etc. it has the name xmlhttp because microsoft who came up
with it evidently envisioned it for sending around xml.
xmlhttp has nothing to do with the gui, the gui has to be coded. on
the other hand XUL is browser specific.

One area where the cross, my understanding is that Google for some of
their dynamic web applications have a transformation server side of
XUL to dynamic html for IE etc. and deliver just XUL to Netscape,
Mozilla etc. however this is a partially remembered bit of web trivia
so don't hold me to it.

On 9/19/05, Martin Carlson <martin> wrote:

>
> Hi all,
>
> I haven't had a close look at this XMLHTTP, but to me it
> don't sound to far from XUL (http://www.xulplanet.com).
> Where you use the mozilla chrome engine to render a gui.
> The "thing" is that you can either render XUL pages
> (much like html pages) remotely in a sandbox mode or
> you can install them ontop of mozilla as a extention,
> which infact run as a "normal" application i.e. thunderbird
> or firefox.
>
> The XUL rendering works in pretty much the same way where
> you have a horrible XML file and thus a DOM tree that you can
> manipulat with java scripts. Thus, using the XmlHttpRequest to
> communicate with the server can make the gui appear interactive
> where all communication takes place in the background as POST and
> GET requests to the server.
>
> Martin
>
> On Mon, 19 Sep 2005, Joe Armstrong (AL/EAB) wrote:
>
> >
> > It's even better than I thought. The Canvas widget *is* in
> > Firefox 1.5 beta 1 and runs out of the box!!!
> >
> > Strangely there are very few working examples on the net to show how the
> > canvas is used.
> >
> > This is amazing - up to now it has been difficult to direct display vector graphics
> > on the web - with the canvas widget this is easy.
> >
> > Wow
> >
> > /Joe
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: owner-erlang-questions
> >> [mailto:owner-erlang-questions]On Behalf Of Joe Armstrong
> >> (AL/EAB)
> >> Sent: den 19 september 2005 11:22
> >> To: erlang-questions
> >> Subject: GUIs - ruby on rails, rico
> >>
> >>
> >>
> >> It seems like my quest for a GUI is almost over.
> >>
> >> Klacke had pointed me at XMLHTTP but I just didn't get it (dumbo) -
> >>
> >> Then I hacked a bit and - WOW. Firstly XMLHTTP is nothing
> >> about XML - it's just allows
> >> a light weight RPC to made from within a web page. So you
> >> connect a bit
> >> of JavaScript to an event - this JavaScript RPCs a server,
> >> the server replies with
> >> a string that the JavaScript interprets (any old string - not
> >> necessarily XML)
> >> and the JavaScript modifies the web page.
> >>
> >> The last bit (the JavaScript modifies the web page) is the
> >> tricky bit - to
> >> do this you need to use the DOM - which is (uuugh) painful.
> >>
> >> Fortunately there are libraries to do this - ruby on rails
> >> uses prototype.js to do this
> >> http://prototype.conio.net/ And Tobbe has written a library
> >> (jungerl/lib/js) to take to prototype.js
> >>
> >> Also of interest is rico http://openrico.org/rico/home.page
> >> (especially their innerHTML
> >> demo) (see
> >> http://openrico.org/rico/demos.page?demo=ricoAjaxInnerHTML.html)
> >>
> >> As far as I can see one could make a pretty snazzy GUI in a
> >> web brower with
> >>
> >>      - a local HTTP server (yaws)
> >>      - XMLHTTP and
> >>      - rico or prototype.js
> >>
> >> Also in the pipeline is an HTML extension <canvas> which has
> >> made it to
> >> safari and mozilla - this is looking good.
> >>
> >> What would be even nicer would be a port of the konfabulator to linux
> >> http://www.konfabulator.com/ - since this (I think) would
> >> solve all my GUI problems.
> >>
> >> This technology is about to explode - so yaws should be well placed -
> >> this means that servers are going to be handling a lot of
> >> lightweight RPCs
> >>
> >> So go hack
> >>
> >> /Joe
> >>
> >>
> >
>
>


Reply | Threaded
Open this post in threaded view
|

Where and how does one find Erlang jobs ?

Håkan Stenholm-3
[I'm posting this somewhat spamish post to this mailing list, as I can't
think of any better or more appropriate place to post it to.]



I'm currently looking for a job (preferably Erlang or some other
non-mainstream language), and would like to notify those who might be
looking for programmers, about my current availability.

I know a number of ways to find Erlang jobs:
* Check this mailing list - thats how I ended up working on YXA
(http://www.stacken.kth.se/projekt/yxa/)
* Check the Erlang jobs web page
(http://www.erlang-consulting.com/jobs_fs.html)
* Contact known Erlang users, this is a bit trickier, but a fair number
of presumably Erlang using companies can be found by checking
www.erlang.se (certified Erlang users) and by checking for whom the
speakers and participants visiting the "Erlang User Conference", work for.

With this post I'm mainly trying to reach/contact those that are not
easily reached by the above mentioned methods e.g. those that are not
publicly using Erlang (as mentioned in recent mailing-list posts),
companies that may dismiss me as unsuited as they may not even know that
they use Erlang, etc ...

Any tips or hints are appreciated.

===============================================


            ___About Me___

* Got a Master of science degree in Computer Science, 1998, at Uppsala
university (Sweden).

* Well versed in C, Java and Erlang.

* Most noteworthy (Erlang) software development jobs:

- Four years (1998/09 - 2002/11) working at Ericsson developing Erlang
code for the AXD301 (Multi Service Switch - handling ATM / IP / phone
traffic / frame relay / ...).
- Seven months (2004/09 - 2005/04) working on YXA (IP telephony server)
and CPL at Stockholm university ("Sektionen f?r IT och Media" /
"Division of IT and media services") to complete the initial YXA
version, so that it can be tested.

* Links to stuff I worked on:
http://www.stacken.kth.se/projekt/yxa/
http://www.stacken.kth.se/projekt/yxa/cpl_implementation.html


            ___Contact info___

Name:      H?kan Stenholm
Email:      hakan.stenholm
Address: Stockholm - Sweden
         (this is also my preferred work location, but I'm willing to move)




Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Ewan Higgs-2
In reply to this post by bryan rasmussen-2
> xmlhttp is an object included with most modern
> browsers which allows a
> scripting engine implemented in the browser to make
> asynchronous http
> gets, posts etc. it has the name xmlhttp because
> microsoft who came up
> with it evidently envisioned it for sending around
> xml.

For what it's worth, a lot of Dashboard widgets on OS
X use the XMLHttpRequest object to asynchronously
update their state.

http://developer.apple.com/macosx/dashboard.html
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
http://developer.apple.com/samplecode/SampleRSS/SampleRSS.html

Wikipedia's entry is suprisingly good for an article
on an API:
http://en.wikipedia.org/wiki/XMLHttpRequest

Ewan


               
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Where and how does one find Erlang jobs ?

Francesco Mazzoli-2
In reply to this post by Håkan Stenholm-3
Hi Hakan,

if you are interested in a job in London, we are currently looking for
four programmers/testers who can start within the next month or so, as
well as support staff (We will be posting the descriptions soon). We are
also looking for two in Rome, and have a few more jobs in the pipeline
in the US. Someone will be calling you soon :-)

To receive updates, register at
http://www.erlang-consulting.com/jobs_fs.html

Francesco
--
http://www.erlang-consulting.com

H?kan Stenholm wrote:

> [I'm posting this somewhat spamish post to this mailing list, as I can't
> think of any better or more appropriate place to post it to.]
>
>
>
> I'm currently looking for a job (preferably Erlang or some other
> non-mainstream language), and would like to notify those who might be
> looking for programmers, about my current availability.
>
> I know a number of ways to find Erlang jobs:
> * Check this mailing list - thats how I ended up working on YXA
> (http://www.stacken.kth.se/projekt/yxa/)
> * Check the Erlang jobs web page
> (http://www.erlang-consulting.com/jobs_fs.html)
> * Contact known Erlang users, this is a bit trickier, but a fair number
> of presumably Erlang using companies can be found by checking
> www.erlang.se (certified Erlang users) and by checking for whom the
> speakers and participants visiting the "Erlang User Conference", work for.
>
> With this post I'm mainly trying to reach/contact those that are not
> easily reached by the above mentioned methods e.g. those that are not
> publicly using Erlang (as mentioned in recent mailing-list posts),
> companies that may dismiss me as unsuited as they may not even know that
> they use Erlang, etc ...
>
> Any tips or hints are appreciated.
>
> ===============================================
>
>
>            ___About Me___
>
> * Got a Master of science degree in Computer Science, 1998, at Uppsala
> university (Sweden).
>
> * Well versed in C, Java and Erlang.
>
> * Most noteworthy (Erlang) software development jobs:
>
> - Four years (1998/09 - 2002/11) working at Ericsson developing Erlang
> code for the AXD301 (Multi Service Switch - handling ATM / IP / phone
> traffic / frame relay / ...).
> - Seven months (2004/09 - 2005/04) working on YXA (IP telephony server)
> and CPL at Stockholm university ("Sektionen f?r IT och Media" /
> "Division of IT and media services") to complete the initial YXA
> version, so that it can be tested.
>
> * Links to stuff I worked on:
> http://www.stacken.kth.se/projekt/yxa/
> http://www.stacken.kth.se/projekt/yxa/cpl_implementation.html
>
>
>            ___Contact info___
>
> Name:      H?kan Stenholm
> Email:      hakan.stenholm
> Address: Stockholm - Sweden
>         (this is also my preferred work location, but I'm willing to move)
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Richard Cameron-2
In reply to this post by bryan rasmussen-2

On 19 Sep 2005, at 21:00, bryan rasmussen wrote:

> xmlhttp is an object included with most modern browsers which allows a
> scripting engine implemented in the browser to make asynchronous http
> gets, posts etc. it has the name xmlhttp because microsoft who came up
> with it evidently envisioned it for sending around xml.

One thing I'd love to do would be to build a message passing library  
for javascript built on top the XMLHttpRequest which can communicate  
with a server written in Erlang. The idea would be a sort of analogue  
of what Distel does for Emacs - it fakes up messages and send/receive  
primitives in such a way that you can see them in elisp.

So, typical applications for this library would be web pages which  
dynamically update when information is "pushed" to them. The simplest  
toy example might be a stock ticker which updates when the price of  
the stock actually changes, not just every 60 seconds when the  
javascript on the web page re-polls. A more ambitious example would  
be to implement something like SubEthaEdit <http://
www.codingmonkeys.de/subethaedit/> as a pure-web application.  
SubEthaEdit is quite a clever little Mac OS X application which  
allows two users on different machines to simultaneously edit the  
same text file and see the changes appear in real time.

Unfortunately the only way I can think of to get this to work over  
HTTP turns out to be a bit of a hack. Luckily though, Erlang is  
probably ideally placed to cope with the hackiness. Perhaps something  
like this would do the trick:

1) The browser makes an XMLHttpRequest to, say, http://hostname/ 
encrypted_erlang_process_id/receive
2) That request is handled by Yaws which simply sits and waits for  
any erlang message destined for the browser. If nothing arrives  
within a suitably conservative http timeout interval (say 30  
seconds), it returns content back over HTTP to indicate that there  
are no messages. If any messages are pending, it sends them all down  
the socket over HTTP under some suitable encoding.
3) The browser interprets what it gets back from the XMLHttpRequest  
and dispatches javascript events corresponding to the underlying  
Erlang messages. These can handled by the client side javascript. The  
client then re-polls as in step one, but perhaps acknowledging that  
it's received the messages so we can have some sort of reliable  
message delivery system.

Additionally, the client-side "send" operation could work making  
XMLHttpRequest to a separate URL, say http://hostname/ 
encrypted_erlang_process_id/send

So, of course, the hacky bit is trying to turn the HTTP "pull"  
protocol into a "push" protocol by having the browser spending all  
its time sitting with an open socket on port 80 waiting for the  
server to return the next message. Having several thousand open  
sockets (one for each connected client) at once is the sort of thing  
which would utterly kill any apache based server infrastructure, but  
the Yaws propaganda <http://www.sics.se/~joe/apachevsyaws.html>,  
support for /dev/poll and kqueue in Erlang on certain architectures,  
and the whole design of Erlang/OTP indicates that it's probably the  
right tool for this hack.

It just strikes me that message passing is probably the right way of  
thinking when you're trying to build these "AJAX" applications for  
the web, and if you can get over the particularly grim way of trying  
to fit it into existing browsers, it might be quite a nice way of  
working.

Does anyone know if anyone's already implement anything like this?  
Would it even work?

Richard.


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

David Hopwood-2
Richard Cameron wrote:
> So, of course, the hacky bit is trying to turn the HTTP "pull"  protocol
> into a "push" protocol by having the browser spending all  its time
> sitting with an open socket on port 80 waiting for the  server to return
> the next message. Having several thousand open  sockets (one for each
> connected client) at once is the sort of thing  which would utterly kill
> any apache based server infrastructure, but  the Yaws propaganda
> <http://www.sics.se/~joe/apachevsyaws.html>,  support for /dev/poll and
> kqueue in Erlang on certain architectures,  and the whole design of
> Erlang/OTP indicates that it's probably the  right tool for this hack.

This will be handled badly by most TCP/IP implementations, even if Erlang
and the web server do everything right.

--
David Hopwood <david.nospam.hopwood>



Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Shawn Pearce
In reply to this post by Richard Cameron-2
I have done something like this back in the ``old days'' of the
web with Netscape 1.1 (it was around 1995 I guess).  We created a
live chat website which used server-side push to update the client
as soon as a new message was available.  For those who don't know,
server-side push is a special MIME-type created by Netscape and
supported in their browser to allow the server to replace the
content of an image.  This was the first animation on the web,
before animated GIFs came along.

Here is the really old Netscape webpage on the topic:

        http://wp.netscape.com/assist/net_sites/pushpull.html

At the time we were using ``A Patchy Server'' (NCSA + the initial
Apache patches) so prefork was just coming out...  there was no way
A Patchy Server would handle the load from the number of clients
we wanted...  so I wrote our own micro-HTTP server based around
select; pthreads were used to initially accept connections or to
accept send message events from clients; a master distribution
thread used select to push data to all of the server-side push
connections currently active.

Within the client we used HTTP frames (note: not iframes, which today
are better visually) to create a 1 pixel high frame at the bottom
of the window.  JavaScript was used on the client to update the
URL of the bottom frame with a ``message'' to send to the server.
This message was then posted within the 1 pixel high frame.
The result is the server got messages immediately, the user never
saw the page refresh, and everyone else saw the update immediately
after the master distribution thread caught up.


One nice thing was we were able to consistently keep the HTTP
server side push channel open to a client for hours at a time.
It even worked through many HTTP proxy servers.

Problems?  Definately.  Our largest one was the simple fact that
a browser getting data from a server-side push whose current
content boundary hasn't terminated wouldn't always render the
content right away.  See, if you terminate the current part in a
server-side push the client assumes the file is over, and when you
open the next boundary the client will clear the content and start
to redraw again.  So we used only 1 content object in the entire
multipart/x-mixed-replace stream.  Frequent use of <p> tags caused
the clients to redraw pretty much immediately after getting data,
but we needed like 8 <p> tags between messages.  :-)


Many years later I did this again to some extent with iframes; the
client used JavaScript to push data into an iframe (which was then
visually invisible) and the iframe posted content to the server.
The response from the server was HTML+JavaScript to update the
client's DOM tree via DHTML.  Worked like a charm.  But I didn't
reimplement the idea of server side push...  we were looking into
the idea though as we wanted some live feedback indicators in a
few places on the GUI.


I have never used XMLHttpRequest; I think it became available
in Mozilla only after I had finished debugging the iframe
implementation.  :-(


Richard Cameron <camster> wrote:

>
> On 19 Sep 2005, at 21:00, bryan rasmussen wrote:
>
> >xmlhttp is an object included with most modern browsers which allows a
> >scripting engine implemented in the browser to make asynchronous http
> >gets, posts etc. it has the name xmlhttp because microsoft who came up
> >with it evidently envisioned it for sending around xml.
>
> One thing I'd love to do would be to build a message passing library  
> for javascript built on top the XMLHttpRequest which can communicate  
> with a server written in Erlang. The idea would be a sort of analogue  
> of what Distel does for Emacs - it fakes up messages and send/receive  
> primitives in such a way that you can see them in elisp.
>
> So, typical applications for this library would be web pages which  
> dynamically update when information is "pushed" to them. The simplest  
> toy example might be a stock ticker which updates when the price of  
> the stock actually changes, not just every 60 seconds when the  
> javascript on the web page re-polls. A more ambitious example would  
> be to implement something like SubEthaEdit <http://
> www.codingmonkeys.de/subethaedit/> as a pure-web application.  
> SubEthaEdit is quite a clever little Mac OS X application which  
> allows two users on different machines to simultaneously edit the  
> same text file and see the changes appear in real time.
>
> Unfortunately the only way I can think of to get this to work over  
> HTTP turns out to be a bit of a hack. Luckily though, Erlang is  
> probably ideally placed to cope with the hackiness. Perhaps something  
> like this would do the trick:
>
> 1) The browser makes an XMLHttpRequest to, say, http://hostname/ 
> encrypted_erlang_process_id/receive
> 2) That request is handled by Yaws which simply sits and waits for  
> any erlang message destined for the browser. If nothing arrives  
> within a suitably conservative http timeout interval (say 30  
> seconds), it returns content back over HTTP to indicate that there  
> are no messages. If any messages are pending, it sends them all down  
> the socket over HTTP under some suitable encoding.
> 3) The browser interprets what it gets back from the XMLHttpRequest  
> and dispatches javascript events corresponding to the underlying  
> Erlang messages. These can handled by the client side javascript. The  
> client then re-polls as in step one, but perhaps acknowledging that  
> it's received the messages so we can have some sort of reliable  
> message delivery system.
>
> Additionally, the client-side "send" operation could work making  
> XMLHttpRequest to a separate URL, say http://hostname/ 
> encrypted_erlang_process_id/send
>
> So, of course, the hacky bit is trying to turn the HTTP "pull"  
> protocol into a "push" protocol by having the browser spending all  
> its time sitting with an open socket on port 80 waiting for the  
> server to return the next message. Having several thousand open  
> sockets (one for each connected client) at once is the sort of thing  
> which would utterly kill any apache based server infrastructure, but  
> the Yaws propaganda <http://www.sics.se/~joe/apachevsyaws.html>,  
> support for /dev/poll and kqueue in Erlang on certain architectures,  
> and the whole design of Erlang/OTP indicates that it's probably the  
> right tool for this hack.
>
> It just strikes me that message passing is probably the right way of  
> thinking when you're trying to build these "AJAX" applications for  
> the web, and if you can get over the particularly grim way of trying  
> to fit it into existing browsers, it might be quite a nice way of  
> working.
>
> Does anyone know if anyone's already implement anything like this?  
> Would it even work?
>
> Richard.

--
Shawn.

  "The reasonable man adapts himself to the world; the unreasonable one persists
   in trying to adapt the world to himself.  Therefore all progress depends on
   the unreasonable man."
  -- George Bernard Shaw


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Mickael Remond-2
In reply to this post by Richard Cameron-2
Richard Cameron wrote:
> So, of course, the hacky bit is trying to turn the HTTP "pull"  protocol
> into a "push" protocol by having the browser spending all  its time
> sitting with an open socket on port 80 waiting for the  server to return
> the next message. Having several thousand open  sockets (one for each
> connected client) at once is the sort of thing  which would utterly kill
> any apache based server infrastructure, but  the Yaws propaganda
> <http://www.sics.se/~joe/apachevsyaws.html>,  support for /dev/poll and
> kqueue in Erlang on certain architectures,  and the whole design of
> Erlang/OTP indicates that it's probably the  right tool for this hack.

That's what I am pushing with J-EAI, ejabberd and out Instant messaging
stuff. If you replace HTTP with a bidrectionnal connected protocol you
can have realtime feedback from the server in your application. This is
how instant messaging application work and this is how you could define
enhanced clients that keep the connection with the server, exchanging
data in both direction. The XMPP protocol is quite nice for that.

--
Micka?l R?mond


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Richard Cameron-2
In reply to this post by David Hopwood-2

On 21 Sep 2005, at 14:08, David Hopwood wrote:

>> <http://www.sics.se/~joe/apachevsyaws.html>,  support for /dev/
>> poll and
>> kqueue in Erlang on certain architectures,  and the whole design of
>> Erlang/OTP indicates that it's probably the  right tool for this  
>> hack.
>>
>
> This will be handled badly by most TCP/IP implementations, even if  
> Erlang
> and the web server do everything right.

What's the problem? If we equip the server with HTTP keepalives then  
then the subsequent XMLHttpRequest should reuse the socket from the  
previous request. All we've got is several thousand persistent  
sockets connected to a listening process on a server. It's the same  
sort of engineering challenge ejabberd has in trying to keep lots of  
connections open at once - and it seems to cope extremely well.

Richard.


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

David Hopwood-2
Richard Cameron wrote:

> On 21 Sep 2005, at 14:08, David Hopwood wrote:
>
>>> <http://www.sics.se/~joe/apachevsyaws.html>,  support for /dev/ poll and
>>> kqueue in Erlang on certain architectures,  and the whole design of
>>> Erlang/OTP indicates that it's probably the  right tool for this  hack.
>>
>> This will be handled badly by most TCP/IP implementations, even if
>> Erlang and the web server do everything right.
>
> What's the problem?

Actually I may have been mistaken; it seems you can get to 10000 connections
fairly easily if using kqueue:
<http://www.cs.princeton.edu/courses/archive/fall03/cs518/papers/kqueue.pdf>

--
David Hopwood <david.nospam.hopwood>