W3C home > Mailing lists > Public > www-svg@w3.org > March 2004

xmlParse with sockets.

From: Jan-Klaas Kollhof <keyjaque@yahoo.com>
Date: Thu, 11 Mar 2004 09:10:20 -0800 (PST)
Message-ID: <20040311171020.98051.qmail@web60102.mail.yahoo.com>
To: www-svg@w3.org

The xmlParse() is nice but I would like to have more.

I would like to have an incremental parser, which can
be fed with data. It should conviniently fire events 
whenever elements are started and finished and when
errors occur.

This would realy be nice with sockets.
Imagine the server pushes XML data to the socket on
the client. The data could be fed to the parse without
knowing if it is complete or not.
This way one can just watch the events of the parser
and not worry about what's coming through the socket.
unmarshallng of arriving data would be sooooooo simple

Here is what I would deffinetly need it for.
I have presentation written in SVG. The presenter
loads the file(master) so do the viewers(clients) of
the presentation. Whenever the state of the master
presentation changes (next slide/item showing) it
transmits this data to a server trough a socket.
The client slides are notified by the server through a
socket connection, too. 
This is basically like the IRC protocoll with some
state buffering on the server.
The main point though is to encode all data
transmitted between server and client (or master
slide) in XML not in some other encoding scheme.
Marshalling like in XML-RPC could be used easyly
compared to having to write one's own codec for each
application ...
There are of course many other ways to use the XML
as well.

I am sure a parser would help/ease application

show a synced slideshow using getURL(polling the
server every 1 s, data marshalling was simple comma
seperated string data)
It would work much better with a sockets and 
data exchange using XML would be even better and with
an incremental parser it would be the simplest.

A similar presentation engine was used for the London
meeting. Data was transmitted using XML-RPC with

Anther example is the IRC client (batik only).

Each message has to be translated/interpreted by the
application logic. This is pretty simple for IRC
but for more complex things XML would be much easyer,
because the tools are already out there for the server
side and client side too(not for SVG though yet :) ).
A message would not be some "strange sequence of
characters" but rather something like:
   <conent>Hello this is a message</content>

The above is much easier to interpret, too, compared
to having to split up strings ...

Anyways, just some thoughts and ideas.


Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
Received on Thursday, 11 March 2004 12:11:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:58 UTC