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

Re: Pushing all the buttons

• To: xml-dev@l...
• Subject: Re: Pushing all the buttons
• From: Kevin Jones <kjouk@y...>
• Date: Thu, 25 Sep 2003 12:28:38 +0100
• In-reply-to: <5.1.0.14.0.20030925104753.01d75ed8@m...>
• References: <5.1.0.14.0.20030925104753.01d75ed8@m...>
• User-agent: KMail/1.4.3

On Thursday 25 September 2003 11:03, Sean McGrath wrote:

Cut ..
>
> In the system, each XML File Loader/Saver is responsible for
> maintaining a native object serialisation for
> each XML instance (in my case, Python/Jython pickles).
>
> At load time, the marshalled object is read *if* the XML has
> not changed. If the XML has changed, it is loaded and a new
> marshalled object is created. At save time, the marshalled
> object is created first, then the plain text XML.
>
> It works a treat and is fast enough to work within the tight
> confines of a HTTP request/response pair thread on a heavily
> loaded portal.
>

That sounds like a pretty neat solution to your problem. I work 
in a different context where incoming documents are completely 
independent so we can't maintain state on the server to assist 
loading. In this case the full parse cost has to be taken for 
each document at TPS up to the 10k kind of range. Binary infoset 
(with optional compression) would be a clear win for us. 

>
> The benefits of that binary thing in the middle being
> platform/product/application neutral are overstated in my
> opinion.
>

We already employ a binary encoding internally within a single 
server but without a standard we can't extend the advantage we 
get from the binary encoding into a bigger environment. 

Kev.
Sarvega Inc.

• References:
  • Re: Pushing all the buttons
    • From: Sean McGrath <sean.mcgrath@p...>

• Prev by Date: Re: Pushing all the buttons
• Next by Date: expriences with hr-xml?
• Previous by thread: Re: Pushing all the buttons
• Next by thread: relax ng public list?
• Index(es):
  • Date
  • Thread