|
Boost : |
From: Oleg Abrosimov (olegabr_at_[hidden])
Date: 2006-10-30 12:12:42
Hello Sebastian,
let me share my ideas inspired by your post.
First of all, I'm confused why there is the 'event' term is used if one
needs to call 'next' method to get the next one? It looks like this is a
good word here though, but it should be used more sequentially.
In a current installment you can safely omit this word and think of your
XMLReader as a
std::copy(std::input_iterator<XMLObject>(std::cin),
std::input_iterator<XMLObject>(), MyIteratorAdapterForXMLObject());
where MyIteratorAdapterForXMLObject - is a user defined iterator that do
the actual processing.
Of course, this view is simplistic, but hope you catch the point:
There is no place for the Event concept!
But don't get me wrong, please, my point is that Boost.XML should be
made around the real Event concept.
My background here is ACE Reactor components (events demultiplexing
subsystem) and more recent Boost.Channel proposal by Yigong Liu (search
boost list for "another snapshot release of Channel framework")
In this light, the proper programming model for XML parsing would be
general event demultiplexing system, with XMLReader seen as a source of
XML events, DTD and Scheme Validators as an event filters (and sources
of Validation events too) and user code as event sinks and/or filters
(of course in such an environment it would be a good way to implement
all other program logic by event sending and responding to them, but it
is up to user and not you as an XML parsing library implementor).
The whole XML processing system would be a collection of Streams (in ACE
terms Stream is a chain of event filters rooted in event sources and
ended in event sinks). Of course the whole system can operate
asynchronously and optionally in a distributed environment.
To conclude, I suggest you to take a look at ACE and try to figure out
how it can be useful to accomplish your goal.
Thank you for your interest in developing such a library for boost,
Oleg Abrosimov.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk