Re: [boost] API Review request: XML APIs for C++

From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2003-06-13 11:59:06

On Fri, 2003-06-13 at 16:11, Stefan Seefeld wrote:
> well, it looks like a mix of things. What you are doing, essentially,
> is wrapping a polymorphic 'do_something' method around a non-C++
> type system, i.e. the real method invocation is done with a 'type()'
> discriminator.

Yes.

> Yes, I can see that, for the xml node types. But for that we don't even
> need anything but a single 'node_proxy' class (with a 'type()' method
> returning an enum).

True.

Though it might be useful in the next layer of the interface. If you end
up with another proxy type that has lots of

switch( raw_node_.some_node_property() )
{
....
}

I use a very similar system in an HTML editor where the entity name is
used to lookup the handler.  Because the lookup can be slow I cache the
result in the node itself.  We might have to expose _private if we
wanted to do that :-(.

Maybe we do need to allow the use of _private in higher level layers.

If so how about something like this?...

template< typename Value_Type, ... >
class document;

template< typename Value_Type, ... >
class node_reference
{
public:
  void value( Value_Type * value )
  {
    node_->_private = value;
  }
  Value_Type * value() const
  {
    return static_cast< Value_Type * >( node_->_private );
  }
};

Or some such???

> I think it is a good thing not to own them, but the semantics should
> be clear.
> 
> >>yes, and you could even make that an 'element_proxy' as you know that
> >>parent nodes are always elements. However, with a flat set of (libxml2)
> >>nodes that wouldn't work any more, so runtime polymorphism would be
> >>lost. Well, may be there is no need for it either. I have to think over
> >>that...
> > 
> > 
> > True and that would fit in nicely with the code I outlined above
> > 
> > node.first_child().do_something( 0 );
> > 
> > Would go through the polymorphic lookup and
> > 
> > node.parent().do_something( 0 );
> > 
> > Would call the same code but without the lookup overhead.
> 
> indeed, though, on further thinking, nodes themselfs don't do anything,
> so we could as well keep this polymorphism outside the node class, and
> let nodes only provide their type as an enum.
> 
> I start to like your node reference class quite a lot... :-)

I am definitely leaning toward "node_reference" rather than "node_proxy"
is that your preferred name too? 

> >>>parse_stream would indeed be even better.  As I recall there are
> >>>functions in libxml2 that allow you to write to the parser as well.
> >>
> >>erm, that's even more confusing, I think. A parser should remain
> >>just a parser, i.e. something that extracts tokens from an input stream.
> > 
> > 
> > It is still just a parser (but works as a state machine).  Check out
> > xmlCreatePushParserCtxt and xmlParseChunk.
> > 
> > Say you need to receive lots of xml files over the internet and parse
> > them all at once.  You could use a thread per connection and have the
> > parsers read from the stream but that would require lots of threads.
> 
> Are you suggesting that all the different xml files should be merged
> into a single dom document ?

No many separate documents each needing there own parser and thread.

> > With the "push" interface you can use async io to read from the sockets
> > and then write the data to the parsers as you get it.  Because the state
> > of the parse is not stored on the stack you do not need a separate
> > thread for each parser.
> 
> yeah, a parser for asynchronous document creation may be interesting.
> But I see that as a somewhat different beast. Simple (local, 
> synchronous) document creation from an xml file doesn't need to
> go over a stateful parser object.

Its not a high priority but it is nice that libxml2 supports it.  

-- 
Hamish Mackenzie <hamish_at_[hidden]>