From: Ian Scott <ian.scott@st...> - 2003-05-13 15:24:32
My own opinion...
A little more detail would be useful.
For instance do you want to be able to save and reload the state of large
complex objects (as vsl does,) or are you intending to use it to parse
control files, etc. If it is more of the former, and is heavily integrated
into VXL then I guess I'd be fine by that. However, I've found that for
large objects the speed/precision advantages of vsl over any text format are
One thought. It would be pretty straightforward to generalise
vsl_b_write(vsl_b_stream&, const myclass &)
vsl_write(vsl_stream&, "Foo", const myclass &)
vsl binary streams would ignore the "Foo" tag, but XML streams would use
that for an element name or something.
On the other hand, if the XML support is to provide a parser for config
files for various applications, or to provide XML IO support for a strictly
limited number of classes, then it is less clear what the advantage to the
VXL community (including you) is for having vxl/v3p/xerces instead of
linking against the library in your private code.
> -----Original Message-----
> From: Kaucic, Robert A (Research) [mailto:kaucic@...]
> Sent: Tuesday, May 13, 2003 3:48 PM
> To: 'vxl-maintainers@...'
> Subject: [Vxl-maintainers] XML suport for vxl
> I was thinking of putting support for XML reading and writing
> into vxl. It
> would entail bringing in a third party package like XERCES
> for parsing the
> XML. Would this be well received?
> Bob Kaucic
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux
> enterprise solutions
> Vxl-maintainers mailing list
From: Andrew Fitzgibbon <awf@ro...> - 2003-05-13 17:30:18
> > -----Original Message-----
> > From: Kaucic, Robert A (Research) [mailto:kaucic@...]
> > Sent: Tuesday, May 13, 2003 3:48 PM
> > To: 'vxl-maintainers@...'
> > Subject: [Vxl-maintainers] XML suport for vxl
> > I was thinking of putting support for XML reading and writing
> > into vxl. It
> > would entail bringing in a third party package like XERCES
> > for parsing the
> > XML. Would this be well received?
> > Bob Kaucic
There have been a few posts recently which talk about
"bringing in" 3rd party libraries to vxl. In general, the ideal
with VXL is that it does not depend on too many 3rd party
libraries. The design of VXL is such that it should behave like
any third-party library you provide. In particular, if your
3rd party library needs its own STL, vxl should be able to use
*that* STL via the VCL compatibility layer, not the other
I use many 3rd party libraries in my code, but there is no need
for the VXL community to know that (unless they look in the
appropriate contrib directory).
There *are* some libraries in v3p which were so badly written or
buggy that they had to be modified to work with VXL, or which
were not easily available elsewhere. On the other hand, we
don't supply gtk or Qt or glut, nor should we supply any
widely available library. We should particularly avoid using
one which is under active development, because then we have to
track every change to the library in our v3p shadow, which rapidly