Networking in SVG and other interfaces

Hello,

I just wanted to let the wg and the developers know about my experience 
with the new networking interfaces in SVG1.2.
I have been playing around with my socket impl in various ways and came 
to the folowing conclusions.

Sockets:
1. Sockets are a great way to have some client-server communication in 
SVG and opens up new possibilities for
SVG applications.

2. I think we need more events though:
ConnectionData   this is already defined.
Connect          it would be good to have an event fired once a 
connection is established.
Disconnect      if the connection is closed one should be notified about 
it through an event.
Error              one should also be notified about any errors that occur.
Connecting     this might not be needed but is kind off nice to have.

3. Encoding
I do think encoding makes sence for the data stream coming from the 
connection. To be more versityle why not have a  String 
encodeString(String in, String codecName) function which can be used 
elsewhere in the script. This way the codec engine can be used for other 
purposes besides the data stream from the socket.

There should be a base64 codec available to the script so one can 
transform data from the socket to base64 for example to create a dataURL 
for images.


For the URLRequest object:
1. Response headers and data should be part of a response object and not 
of the request object.
2. We need more events:
    URLResponse    This may contain the response object once the first 
part of a respnse is arriving.
    PartialData         This should contain the partial data arrived and 
the response object
                               plus additional information about the 
remaining data to be loaded.
                               This way one get's progress information 
about the data being loaded instead of only having one event for all 
data and headers.
    Connecting      
    Connect
    (Submitting)
    Disconnect     These are events for state handling. This might be 
more usefull then to periodically check the requestState of the request 
object.

3. parseXML should not be part of a response oject it should be 
seperated and available through the window interface.


Since there is a lot of functionality for handling data that viewer 
impl. have to use why not expose some of these functionalities to the 
script.
 1. parseXML    for parsing XML. preferably it would be nice to have an 
incremental parser one could feed data to which then parses that data 
and spits out a DOM.

2. encode(String in, String codec) and decodeString(...)  It would be 
nice to be able to do some Base64 encoding/decoding and some URLencoding 
...

3. unzip(String data) Since the viewer has to impl. unziping anyways it 
would be quite handy if one could use this functionality. Examples would 
be socket connections which transfer image data (e.g base64 encoded) or 
xml data....  A Stream object would be nice too.


this should be it for now. I am sure there is more, but I can't think of 
anything right now(jetleg is still working on me).



Jan

Received on Thursday, 16 September 2004 09:20:21 UTC