Re: [Texi2html-bug] Re: FSF assignment?

[Derek Price]

Patrice Dumas wrote:

> The plan is to move the whole tree into texinfo.

Okay.

> I would be happy to relicense my work under any free software license,
> even public domain.

Thanks!

> About making something really modular, I don't know how feasible it is.
> Currently the separation between output and texinfo parsing is quite
> good, and now that texi2html can process more than one texinfo file,
> there is a beginning of separation from the main program and texinfo 
> processing. However, the processing is still very linked with the init
> file, and many data structures are initialized in the main loop. I don't
> know which interface should be done for something acceptable as
> stand-alone module.

Static stuff that gets initialized in the main loop should be
initializable in the new package instead without many changes.

Stuff from the current init files and command line is already stored in
a package internally (Texi2HTML::Config), so it should be trivial to
translate init files into submodules instead (Texi2HTML::Config::HTML,
Texi2HTML::Config::Info, Texi2HTML::Config::DocBook, ...).  Then an
arbitrary package that implements Texi2HTML::Config could be passed in
as an argument to the main Texi2HTML package when loading the parser.

The texi2html.pl script could still create a Texi2HTML::Config package
on the fly based on command line arguments as it does now, then pass
that package to the Text2HTML package to configure it.

I would probably go a little further and enable multi-threading.  For
that, the config package would need to be instantiated with new() and
passed around as an object, like $config.  That is just a matter of
initializing a hash via the package variables in new(), though, and also
fairly simple to accomplish (in fact, it should be possible to implement
this in a few lines in the parent Texi2HTML::Config package and ignore
it in the specific configurations).  Then all current references like
"Texi2HTML::Config::VARIABLE" would be replaced with
"$config->{VARIABLE}", but that is also fairly straightforward and could
probably be accomplished quickly with sed.

Of course, with the new functionality and this packages new place in
Texinfo, a Perl module name like Texinfo.pm (as opposed to Texi2HTML.pm)
and the corresponding sub-namespaces might make more sense than the ones
I suggested above.

> That being said, it is the right time for a complete reorganization of
> the interfaces toward something more modular. I think we can break
> everything for the merge in texinfo (and I already have broken quite a
> bit...).

How broken is it?  If it works now, I could make a quick pass at
reorganizing as I just suggested, but I don't want to have to fix a
bunch of stuff you are already working on in order to test my changes.
For that matter, I don't want to start this work myself unless I know it
can be released under the Artistic license.

Thanks,

Derek
-- 
Derek R. Price
Solutions Architect
Ximbiot, LLC <http://ximbiot.com>
Get CVS and Subversion Support from Ximbiot!

v: +1 248.835.1260
f: +1 248.246.1176