Re: [WMVS] Some initial thoughts on code M12N...

Terje,

Thanks for starting this discussion. Plenty of good ideas and useful 
basis for discussion.
More comments inline.

On Aug 10, 2004, at 2:21, Terje Bless wrote:
> multiple front-ends (e.g. commandline, native GUI, WebService, etc.)
> and pluggable backends (e.g. multiple XML Processors).
> the modules should be OO rather than just a bunch of externalized 
> subroutines.

Yes, yes and yes.

> I think all of the above is uncontroversial judging by our discussons 
> of this
> in the bi-weekly IRC meetings, non?

Maybe... I'll note that the previous thread [1] on multiple front-ends 
/ pluggable backends has not received a lot of participation other than 
from myself and Nick (note that I failed to answer Nick's comments, my 
bad). Hopefully, this indeed means that the ideas developed are 
uncontroversial, not that no-one will touch it with a ten-foot-pole. 
Right?

[1] http://lists.w3.org/Archives/Public/public-qa-dev/2004Jul/0010.html


> Chapter 2: The Branch Situation


> we can split out m12n completely, in a separate CVS module even.
> [...]
> So I'm thinking that the smart way to go about this is to start 
> building the
> modules as a completely separate deliverable from the main Validator 
> code.

I think this idea was stated during one meeting, and I agree that so 
far it seems to hold the best simplicity/pain ratio.

Simplicity: no branching, no merging, ease of testing, ease of 
distribution too (CPAN), etc
Pain: rather minimal, based on my experience with other such 
structures. The only problem I ever ran into was maintaining 2 versions 
(CVS in /usr/local/perl/modules + stable-cpan-make-install), and that 
can be done simply by setting @INC.


> Chater 3: Where The Devil Resides
>
> My thought has always been that we should start by modularizing the 
> code and
> featureset we already have, in lieu of adding significant new features 
> in the
> M12N code. e.g. we should modularize the SGML Parser backend — with 
> both
> OpenSP and jjc's SP implemented, as proof of concept (maybe) — without 
> adding
> any real XML Processors; this to avoid changing too much and getting 
> into
> stabilization and integration issues.

Sorry if this is really dumb, but isn't a modular architecture 
precisely made to avoid such questions, i.e one can work on an OpenSP 
wrapper module while another tests/creates XML processing modules? Or 
are you talking about priorities?

> Since our current use of «onsgmls» is fairly simple — grotty 
> complicated code,
> but very simple use of OpenSP — we could even conceivably adopt
> SGML::Parser::OpenSP to replace the calls to «onsgmls» in the 
> production
> Markup Validator without waiting for any kind of complete M12N to 
> happen;
> about the only requirement would be to be comfortable that the S::P::O 
> code is
> stable and without major bugs (and feature complete for the bits we 
> need).

The above seems to answer the questions you asked in :
>  start modifying the
> mainline Markup Validator to make use of the modules instead of its own
> internal subroutines. Possibly all in one fell swoop, but possibly 
> little by
> little as we become comfortable with deploying the modules in 
> production.

little by little seems not only possible, but also preferable (easier 
to test(?), release often)

> Chapter 4

No comment, looks good.


> Chapter 5: Stay Mobile!
>
> One key reason for the extra levels of abstraction (extra layers of
> subclasses) here is so the actual code in what is «check» today is 
> reduced to
> be as little as possible.

... and probably having a much lower level of entry for anyone wanting 
to "play with" the validator.

Today, someone might be able to create, say, a recursive validator 
based on ours, but not without a lot of chest pain, headaches, mood 
swings, consumption of various substances to ease the effects of the 
above. Not to mention it's impossible to keep the resulting code in 
sync with progresses and bugfixes in the WMVS.

> Chapter 6: Stumbling Into Apotheosis

>
> But most importantly, I think we should be running normal development 
> on 0.7
> (and maybe even 0.8 and 0.9) in paralell with this effort. I do not 
> want to
> stop mainline devlopment for production while we try to implement any 
> big
> radical changes to the architecture.

This sounds reasonable, although I do not see that many things in 0.8 
or 0.9 that would take muych time, hence I'm rather hopeful that we'll 
be able to give m12n a lot of attention soon (especially given how e.g 
bjoern/nick seemed willing to work on it "at last").



-- 
olivier