Jeff Garland wrote:
From: "Jeff Garland" <[EMAIL PROTECTED]>
Anyway, my conclusion is there is nothing preventing using
serialization for XML other than the time and energy to do
it.
As I already said, my experience is that this theory sometimes proves wrong.
I understand. And I would like to see a more complete evaluation of this issue.
However, this thread started b/c of 2 posts that from Robert and Matthias that
led me to believe there was something about the design that would prevent
extending to XML. I was curious b/c I hadn't seen anything that was a blocker.
After further discussion it appears I over extended their comments. So
I am back to where I started -- I currently don't see a reason that
the library design prevents extensions for XML formats -- doesn't
mean that it is guaranteed, just that it isn't obviously broken.
I believe that the biggest problem is that the current library does
not have any "begin class serialization"/"end class serialization" hooks,
which archive classes can interpret. IOW, you want to surround a serializated
class with <something> and </something>, but the library passes only a stream
of ints to you arhive class.
Some other library (which name I can't remember now, sorry), used something
like 'describe', and there were explicit 'beginComposite' function.
Such functionality would be very desirable to have in the reviewed library,
even if XML archive is not gonna be written right now.
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
