Method for server push via Never-ended documents (xhtml, xml, svg)...

View: New views
2 Messages — Rating Filter:   Alert me  

Method for server push via Never-ended documents (xhtml, xml, svg)...

by Félix Hauri :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I would like to present an idea of ``never-ended'' document,
following the notion of ``Progressive rendering''.
  http://www.w3.org/TR/2004/WD-SVG12-20041027/progressiverendering.html
( and of course, become some observations from your expertise ;)

There is a work about:
 - Remote monitoring via svg dynamiques files (even mixed in xhtml docs).
 - Minimise network traffic and server load,
 - Reducing network connections to maintaining only one.

My first approach was to use NPH-Server-Push in
response to a regular XMLHttpRequest, in multipart mode.
  http://perso.f-hauri.ch/~felix/svg/cpu.svg

The ``traditional'' method (using XMLHttpRequest in javascrit loop)
(You could look the Sun over Bex(VS/Switzerland) at
  http://www.websolaire.ch/power.svg ;)
work fine but use more bandwidth because of sending HTTP headers
at each exchange, and more server load because of cgi fork at each
exchange.

My proposal is to send the xhtml *and* the pushed values
in the only one first connexion to server, as one xhtml
stream with the form:
<html>
 <head>
  <script type="text/javascript">
   ...
   function initvars(values) {
     ...
     stream_elm.removeChild(stream_elm.lastChild);
   }
   function do1job(values) {
     ...
     stream_elm.removeChild(stream_elm.lastChild);
   }
  </script>
 </head>
 <body>
 ...
  <div id="stream" style="display:none">
  <script language="javascript">initvars(1,2,3,4)</script>
--- cutted end of never-ended-xhtml stream ---

There is a prototype you can look (and download) at
  http://perso.f-hauri.ch/~felix/marcm/vmstat.cgi
The perl is not very well writen, and the javascript
could only be read in dumped stream, you could blame me,
but I'm alone and don't dispose as many time i need...
(I wanna clean them, isolate functions, export them as
 CGI object library, but this could take some time ago)

This demo script could work in standalone mode, on linux system:
 $ su - nobody
 $ cd /tmp
 $ wget http://perso.f-hauri.ch/~felix/marcm/vmstat.cgi/download/vmstat.pl
 $ chmod +x vmstat.pl
 $ ./vmstat.pl
 Server started at port 8881
You could look a dump with -x parameter:
 $ ./vmstat.pl -x
 Set-Cookie: delay=1; path=/; expires=dim, 07 jun 2009 11:17:26 CEST
 ...
 Content-Type: text/xml; charset=utf-8

 <!DOCTYPE html
 ...
 </p>
 <div id="stream" style="display:none">
 <script language="javascript">initvars(1035880,2007920,1)</script>

Firsts remark:
 - Idealy, the </body> must be present, but if so, the client
   (tested with mozilla and opera) will close network connexion.
 - Idealy, further request must be sent in following the first
   request, in the same network connexion, but there are
   limitation from clients.

In hope this could inspire your team to improve XHTML (and/or SVG)
specifications, and awaiting for your observations, please become
my thanks for your efforts to maintaining and make evoluate publics
standards.

--
 Félix Hauri - Informaticien consultant  |\      /|       ___  _
 --------------------------------------  | \ __ / |      /    -   /   o
 7, rue Centrale / CH-1450 Sainte-Croix  | .    . |     /_  ___  /
 Tél: (+41/0) 24 454 54 04  Fax:..54 00  |   /\   |    /   /__/ /   /  \/
 http://www.f-hauri.ch                   | \ __ / |   /   /__  /_  /_  /\
 email: felix@...                  \ ____ /   ---------------------



Re: Method for server push via Never-ended documents (xhtml, xml, svg)...

by Rick-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Félix:

I don't speak for the SVG Working Group, ex-member.  There has been
discussion in the past about streaming SVG and how it should work.  I
don't know what the sate of that is.

You can achieve a similar effect now using XMLHTTPRequest (Ajax) and
multipart/mime by leaving the connection open so you don't have the
overhead of new connection objects.

The industry term for this is Comet.

I pan to implement this but I haven't done so yet.

Here are some links that I have put aside for further study:

http://www.captain.at/ajax-file-upload.php
http://www.megasolutions.net/javascript/ajax-multipart-problem-75580.aspx
http://bytes.com/groups/javascript/648903-ajax-multipart-problem
http://forums.java.net/jive/thread.jspa?messageID=327125
http://prototype.lighthouseapp.com/projects/8886/tickets/498-prototype-messes-up-the-multipart-boundary

On Fri, May 8, 2009 at 6:05 AM, Félix Hauri <felix@...> wrote:

> Hi,
>
> I would like to present an idea of ``never-ended'' document,
> following the notion of ``Progressive rendering''.
>  http://www.w3.org/TR/2004/WD-SVG12-20041027/progressiverendering.html
> ( and of course, become some observations from your expertise ;)
>
> There is a work about:
>  - Remote monitoring via svg dynamiques files (even mixed in xhtml docs).
>  - Minimise network traffic and server load,
>  - Reducing network connections to maintaining only one.
>
> My first approach was to use NPH-Server-Push in
> response to a regular XMLHttpRequest, in multipart mode.
>  http://perso.f-hauri.ch/~felix/svg/cpu.svg
>
> The ``traditional'' method (using XMLHttpRequest in javascrit loop)
> (You could look the Sun over Bex(VS/Switzerland) at
>  http://www.websolaire.ch/power.svg ;)
> work fine but use more bandwidth because of sending HTTP headers
> at each exchange, and more server load because of cgi fork at each
> exchange.
>
> My proposal is to send the xhtml *and* the pushed values
> in the only one first connexion to server, as one xhtml
> stream with the form:
> <html>
>  <head>
>  <script type="text/javascript">
>   ...
>   function initvars(values) {
>     ...
>     stream_elm.removeChild(stream_elm.lastChild);
>   }
>   function do1job(values) {
>     ...
>     stream_elm.removeChild(stream_elm.lastChild);
>   }
>  </script>
>  </head>
>  <body>
>  ...
>  <div id="stream" style="display:none">
>  <script language="javascript">initvars(1,2,3,4)</script>
> --- cutted end of never-ended-xhtml stream ---
>
> There is a prototype you can look (and download) at
>  http://perso.f-hauri.ch/~felix/marcm/vmstat.cgi
> The perl is not very well writen, and the javascript
> could only be read in dumped stream, you could blame me,
> but I'm alone and don't dispose as many time i need...
> (I wanna clean them, isolate functions, export them as
>  CGI object library, but this could take some time ago)
>
> This demo script could work in standalone mode, on linux system:
>  $ su - nobody
>  $ cd /tmp
>  $ wget http://perso.f-hauri.ch/~felix/marcm/vmstat.cgi/download/vmstat.pl
>  $ chmod +x vmstat.pl
>  $ ./vmstat.pl
>  Server started at port 8881
> You could look a dump with -x parameter:
>  $ ./vmstat.pl -x
>  Set-Cookie: delay=1; path=/; expires=dim, 07 jun 2009 11:17:26 CEST
>  ...
>  Content-Type: text/xml; charset=utf-8
>
>  <!DOCTYPE html
>  ...
>  </p>
>  <div id="stream" style="display:none">
>  <script language="javascript">initvars(1035880,2007920,1)</script>
>
> Firsts remark:
>  - Idealy, the </body> must be present, but if so, the client
>   (tested with mozilla and opera) will close network connexion.
>  - Idealy, further request must be sent in following the first
>   request, in the same network connexion, but there are
>   limitation from clients.
>
> In hope this could inspire your team to improve XHTML (and/or SVG)
> specifications, and awaiting for your observations, please become
> my thanks for your efforts to maintaining and make evoluate publics
> standards.
>
> --
>  Félix Hauri - Informaticien consultant  |\      /|       ___  _
>  --------------------------------------  | \ __ / |      /    -   /   o
>  7, rue Centrale / CH-1450 Sainte-Croix  | .    . |     /_  ___  /
>  Tél: (+41/0) 24 454 54 04  Fax:..54 00  |   /\   |    /   /__/ /   /  \/
>  http://www.f-hauri.ch                   | \ __ / |   /   /__  /_  /_  /\
>  email: felix@...                  \ ____ /   ---------------------
>
>
>



--
Cheers!
Rick