Re: a comment [COAS]

[Nick Mathewson <nickm@mit.edu>]

You wrote:
>I've been on the Linuxconf mailing list for about a year.  About 6
>months ago, I think, Jack posted a notice that he and COAS were working
>together in some mannor, I don't remember the details, and basically
>Linuxconf was going to take the place of COAS.  Evidently they felt that
>Linuxconf had enough of a head start that it would be smarter to work
>with Jack on integration than to start from scratch.
>
>I'll post a message to Jack and ask him if this went TU or if it's still
>the plan.

Great!  Even if it didn't, I agree that (should we chose COAS), it would
be a Good Thing to port Linuxconf modules, rather than writing our
own from scratch.  (Please let me know what Jack says.)

>As a side note.  If COAS and Linuxconf have decided to remain seperate,
>we should tip the scales more toward the end-user than the programmer. 
>I realise it may benefit the end-user in the end if it's easier to
>program modules, but unless it's a huge difference I would vote for the
>versatility over the API in the interest of the project goal.

Hmmm.  I agree to a point, but again, it largely depends on _how big_
the difference is.  As near as I can tell, COAS (when completed) and
Linuxconf, promise to be roughly equally usable to the users.  The
main problem with that analysis is, of course, that COAS is not
finished, and neither utility will have the facilities to handle the
entire SEUL environment (unless we write them in).

The reason I'm concerned about API's is that, in an ideal world, we'd
like for Joe Average Developer to be able to write modules for
whatever tool we choose with minimal effort and maximal
maintainability.  Keep in mind that I'd like to hack whatever tool we
choose to support dotfiles as well as system files -- and there are
more kinds of dotfiles out there than you can shake a stick at.
Ideally, I'd like to be able to write a simple module for a each new
dotfile format in under an hour or so, and not have too much heavy
coding involved -- or better yet, make a module format so simple that
developers will write modules for _their own_ tools, rather than
giving the user a simple text file and leaving it at that.

 [snip]
>Maybe if we aproach him he'll be willing to work with us on
>compatability issues and such.  
>
>Should I ask, or would an admin leader rather handle that?

Let me know what Jack says about the existing effort; then I'll ask.

Judging only from the divergence between the API's, it seems that
making either tool's modules work well with the other may be rather
difficult.  Perhaps we'd be better off porting any missing modules
from one to the other.  (But then again, if we _could_ make e.g.
Linuxconf modules run under COAS, then a great many maturity concerns
would evaporate rather briefly.)

-- 
Nick
===
SEUL-Leaders list, seul-leaders-request@seul.org
===