RE: [xml-dev] Microsoft's vision of data and the role of XML in that context

["Joshua Allen" <joshuaa@microsoft.com>]

Yes, I think I got a bit carried away in trying to explain a particular benefit of the pull model. 

The main point I was trying to get across is that the average developer doesn't need to worry about any complicated concepts when gluing a reader to a writer, which is probably 85% case for us.  For example:

XmlWriter x = new XmlWriter(Response.Output); // Write to HTTP response
XmlReader r = new XmlReader(mUri); // connect to SQLXML or something
while (XmlNode n = r.Read()){
        // do any custom dispatch here
        x.Write(n);
}

On the other hand, as a few people have pointed out, it puts some extra burden on component vendors, since component vendors who want to support the users typified above will need to make components that accept writer as input and/or provider reader as output. 

Like Bill mentioned, it is really easy for someone to do this by buffering the whole result, and many people do this.  But for component vendors (like Microsoft) who need to support smaller memory footprint and wide range of potential scenarios, we have to do extra work in the components.

Overall, I think the tradeoff is good for two reasons.  First is that it makes things easier for the 80% of programmers (80% of whom still haven't done any XML programming yet :-)).  Second, the things like buffer synchronization, worker threads, and so on are risks to platform stability and performance if done incorrectly.  The code example above is a nice, tight, loop -- it is hard for users to screw it up in a way that hurts the overall system.  And while that means that vendors like MSFT bear more direct responsibility for any threading/buffering issues, it also means that we have more direct control over these issues and can presumably fix or improve better.  It also means that we can do work in the runtime and programming model to make it a lot easier for component vendors to get their own optimized async/buffering (or even some naïve version "for free"), all while hiding this from most developers. 

I think a good analogy is the comparison between custom C++ memory management and C# garbage collection.  There are legitimate cases where strong C++ guys can do a better job for specific scenarios if they write all the memory management code themselves.  But in the vast majority of cases, the C# garbage collector will give better overall performance, with no need for the programmer to do explicit memory management.  Hopefully that is how average developers will be able to think about gluing XML streams together... 





-----Original Message-----
From: Aaron Skonnard [mailto:aarons@develop.com]
Sent: Wednesday, September 18, 2002 5:06 PM
To: xml-dev@lists.xml.org


> Joshua Allen wrote:
>
> > The forward-only "pull model" is quite important because many
> > of our low-level scenarios involve pipelined processing of XML,
> > where performance and working set are critical. 
> > "Pull to read, push to write" makes it easy for developers to
> > write components which automatically "just works" in a pipelined
> > environment.
>
> Could you elaborate on this?  I'm confused.
>
> If every component follows this model, how do you plug
> two of them together? 


I'm confused too. IMO, XML processing pipelines are much easier to
implement in SAX that with the .NET APIs (this is actually the
1-out-of-10 scenario I alluded to in my previous post). Since the same
interface, ContentHandler, was used for both reading and writing, it was
trivial to plug them together. This is not the case in .NET. Do you mean
a pipeline of readers or a pipeline of writers, but not where one feeds
into the other?

-aaron

......................................................
. Aaron Skonnard, DevelopMentor (http://skonnard.com).
.  Essential XML Quick Reference available online!   .
.    Download PDFs: http://www.develop.com/books     .
......................................................




-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>