Re: [boost] Re: generic polyvalent input/output ['pickle']

From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2000-11-17 06:05:31

Hi,

Although I'm the one who suggested XTL in the context of serialization,
I'm not the author of XTL. I have tried to contact the author regarding
a submission to boost but so far I haven't been able to reach him. His
name is Jose Orlando Pereira, and he seems to be associated with the
Universidade do Minho in Portugal. He does not reply to e-mail, and I
can't reach his personal home page, nor the home page of the 
university.

So, please do not judge XTL as a library ready for submission to boost.
Since I'm not the copyright holder, I can't submit XTL at all neither
legally nor morally. The license is LGPL, and thus incompatible with the
boost requirements. Only the original author has the authority as
copyright holder to change the license, and submit it for boost if he so
chooses.

What I can do, however, is to point to XTL as an example of how to solve
some of the issues with serialization. In this context, it's only fair
to try to address the critique that has been raised here.

>  - cfile_buffer is described in the documentation, but I could
> not find it in the implementation anywhere at all.   What's
> the equivalent iostream buffer?
>
>  - text_format doesn't support input (yet?).  text_format doesn't
> properly escape special characters in string output.  For example,
> a " within a string makes the resulting output un-parseable.

The documentation and the implementation are not completely synched. 
In particular, the cfile_buffer has not been implemented. It is 
correct that the text_format only supports output, and only to a 
limited extent.

>  - The documentation starts with explaining the intrusive way of
> adding a serialization function first.  This may shy away users,
> since there is indeed a non-intrusive way (global function) as
> well.

Granted.

>  - The copyright is LGPL, which seems to be incompatible with
> the boost copyright policy.

This is a problem, and can only be solved if the copyright holder can be
reached, and then chooses to change the license and let XTL be submitted
for boost. Hypothecially, I'd be willing to take the responsibility of
preparing XTL for submission, if the original author can't for whatever
reason. 
If the consensus here is that XTL (with the proper polishing work) might
be suitable for boost, I'd be willing to make more efforts to try to
reach the author, and see if the licensing issue could be solved.

>  - I think that the "buffer" layer can be removed entirely.
> I believe the correct way is to write a streambuf for C files
> and fixed-size memory areas.  (std::stringstream is close (but
> not fixed-size) to a memory area, btw.)

Could you elaborate on this idea a bit more?

I certainly agree that the buffer layer is poorly documented, and it
should be great to clean this area up, since it's the weakest point of
the concept as I see it.

>  - The interface does not use iterators.  For example, writing
> any container (even user-defined ones, whithout assuming they
> have begin() and end() methods) can be more flexibly achieved
> by iterators.  And reading is happy with a back_insert_iterator
> or similar.

Yes.

The following would obviously have to be addressed in the clean up:

>  - Page 9 of the documentation mentions "partial specialization
> of template functions".  This is a concept alien to ISO C++
> (at the moment).  Overloading with partial ordering is the term
> to be used.
>
>  - The smart pointer example assumes an internally-counted
> implementation, which should at least be explained explicitly.
>
>  - Lots of ugly C-style type casts in the code.
>
>  - Some macros are used without any deeper qualification.
> Clashes may occur.
> 
>  - Include guards start with double underscores, which thus
> infringe on the identifier space reserved for implementations of
> C++.
> 
>  - The code is not in a namespace.

One personal critique is the distinction between "simple" and "composed"
names in the interface. I'm not perfectly sure, but it might be possible
to consolidate this to only one name, and thus simplify the interface
further.

Also, the VC++ port is not acceptable at present.

The main problem reamins: The copyright holder seems to be unreachable
by e-mail or web, and has been so for a while.
I'd be obliged if people would give an indication of whether I should
spent some more time and energy to try to track him down, i.e. whether
XTL as such (with the proper work) has a chance to be adopted into
boost. Then we would have to figure out who should do the needed work,
but I'm sure that could be solved given the good cause.

Greets,

Asger Alstrup Nielsen