[gobo-eiffel-develop] GOBO and eXML

[Andreas L. <no...@sb...>]

I just released a new version of eXML (http://www.sourceforge.net/projects/exml).

This version includes a lot of the changes we were discussing the past
couple of days, though not all of them yet (;

Here is my TODO-list:
1) Wait for GOBO-nized UCSTRING
2) remove eXML comments at the end of each class
3) add/replace GOBO std indexing clauses
4) clean up examples (make parser choice in ebook)
5) documentation (use docbook?)
6) find better name (XM_) for DEFAULT_POSITION and DEFAULT_SOURCE
7) build system 
	*)make .mk makefiles in parser backends real stand alone Makefiles
	  don't forget to update the global makefiles
 *) somehow merge build system with GOBO's build system
8) C_STRING_HELPER
 *) should go into a general Eiffel<->Cluster in GOBO (utility?)
9) expat support for Visual Eiffel and general HACT support 

ad 7)
External C dependencies make life really really hard... I have my
examples all setup very general. Due to the factory class they check
what back end parsers are compiled in and you can choose your favoriteat
runtime via a command line argument. This brings in some trouble at
build time though: I want to provide a simple way for the user to choose
at build time what backends he wants to have compiled in. This is
important because not everybody wants to go through the hassel and
install expat on his system. Also a possible compile_to_jvm is not
possible with expat dependencies in the build configuration. Now how can
I do that? With Makefiles of course, but they do not work on Windows ):

Do you have any idea on how I can solve that issue?

ad 8)
In order to get actual data from expat I need to convert all kinds of C
strings (fixed length, zero terminated, ...) into Eiffel Strings (or
UCSTRINGs) C_STRING_HELPER is what I built to do that, but it is
compiler dependent of course. I think this is a good candidate for GOBO
itself (outside of the proper eXML clusters) - maybe with a few
modifications.

What do you think? If we make (a modified variant of) C_STRING_HELPER a
part of GOBO, I think we should do so before the actual eXML merger. It
is a smaller cut and thus takes less time. Once it is in GOBO (CVS is
sufficient) I can adjust eXML to work with the new GOBO (which then
includes C_STRING_HELPER). This in turn will make the eXML meger smaller
and thus easier. I believe that cutting up the big job into several
smaller jobs will have several benefits. There will be visible progress,
regressions won't hit us so badly and thus we will save time.

Andreas