[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Pushing SAX events out onto the Web?

• To: "'Roger L. Costello'" <costello@m...>, <xml-dev@l...>
• Subject: RE: Pushing SAX events out onto the Web?
• From: "Didier PH Martin" <martind@n...>
• Date: Wed, 14 Aug 2002 14:06:28 -0400
• Importance: Normal
• In-reply-to: <3D5A84FA.CC485029@m...>

Hi Roger

Roger said:
I have a sensor that is collecting information over time.  As the data
is collected I want to stream it out to clients.  The data within each
element is huge.  Consequently, the number of SAX events would be small
compared with the size of the data.

I understand your point that sending a bunch of tiny event messages is a
bad idea.  I agree.  Streaming an XML string is preferred.  I think that
I can use SAX to stream XML strings (I believe that this is what Francis
was saying).  For example, for the SAX startElement method:

public void startElement (String ns, String local, 
                          String qName, Attributes atts) {
   -- startTag = XML string representing the start element
   -- along with attributes, and namespace, e.g.,
   -- <boeing:aircraft type="747">

   socket.send(startTag);
}

Is this what ya'll are saying

Didier replies:
>From the code snippet I deduce that you are using Java as an
implementation language. If you are using RIM or IIOP you'll have to
include the marshaling encoding/decoding in your equation.

Since you'll probably experience some network latencies, I would
recommend that you send the data in batch. Most preferably in a single
XML document and get the clients parse and process the XML document.
This will regulate the data flow between the client and the server. I
remember having done that for a smoking robot a couple years ago. The
XML document will act as a kind of buffer and tend to smooth the
latencies between the clients and the server. It is also easier to
server more than one client this way.

>From your problem statement it seems that the server has enough time to
parse and select only the pertinent elements. If the elements contain a
lot of data then packaging several of them in a single document make
sense. If network bandwidth is an issue, then compression may be
envisioned. If the server has not enough power to compress or any other
constrain restrain you to use this particular solution, then maybe a
complete new approach is demanded here. An approach that may not
necessarily use any XML technology.

Cheers
Didier PH Martin

• References:
  • Re: Pushing SAX events out onto the Web?
    • From: "Roger L. Costello" <costello@m...>

• Prev by Date: Re: XHTML 2.0 and the death of XLink and XPointer?
• Next by Date: Re: Can XLink be fixed?
• Previous by thread: Re: Pushing SAX events out onto the Web?
• Next by thread: Re: Pushing SAX events out onto the Web?
• Index(es):
  • Date
  • Thread