W3C home > Mailing lists > Public > www-svg@w3.org > May 2009

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

From: Cyril Concolato <cyril.concolato@enst.fr>
Date: Mon, 11 May 2009 11:49:24 +0200
Message-ID: <4A07F4A4.3060808@enst.fr>
To: Félix Hauri <felix@f-hauri.ch>
CC: www-svg@w3.org
Hi Félix,

Indeed, the notion of 'never-ending' document is interesting as shown in your demos. I would like to point out an article which might help you. I wrote a paper on streaming of SVG for the conference Document Engineering which dealt with similar problems: long running delivery of SVG content, control of the bandwidth, control of the client load. I also had additional constraints on synchronization and the use of declarative solution (no scripting). 

My experience is that SVG's progressive rendering is fine for the rendering of never ending documents but with a few remarks. The spec does not put any constraint on the refresh rate, so you should not expect refresh with a fine granularity. Additionally, if you want a large granularity for the refresh, you should use the externalResourceRequired attribute. You can also use the discard element to destroy previously sent elements which have become outdated. I did some experiments on streaming of SVG cartoons over HTTP or RTP. Even though simple HTTP was working, the problem is that the server is not made to control the timing precisely. I had to give it additional time information. Using RTP and a streaming server like Darwin was much easier, the server would push the data when needed (as indicated by timestamps). The problem was also the fact that by just adding elements at the end of the document, or by deleting old elements, you cannot modify the order of the document (whi
ch is sometimes needed) without scripting. I had to built a dictionnary of elements and reuse them in a display list (like Flash) which I would resend at each frame. All this was done without using other features than SVG Tiny 1.2 at the client side. You can have a look at this paper:

http://www.tsi.enst.fr/~concolat/Papers/2007%20-%20DocEng%20-%20Timed-fragmentation%20of%20SVG%20documents.pdf

There are other solutions for that problem, e.g. if you uses LASeR/DIMS updates on top of SVG. You can for example just change an attribute value, or insert elements any place in the document... You can have a look at the 3GPP Dynamic and Interactive Multimedia Scenes spec:

http://www.3gpp.org/ftp/Specs/html-info/26142.htm

Regards,

Cyril

Félix Hauri a écrit :
> 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@f-hauri.ch                  \ ____ /   ---------------------
> 
> 


-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Département Traitement du Signal et Images
/Dept. Signal and Image Processing
Ecole Nationale Supérieure des Télécommunications
46 rue Barrault
75 013 Paris, France
http://tsi.enst.fr/~concolat 
Received on Monday, 11 May 2009 09:49:46 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:42 GMT