tunes admin.

[Fare Rideau]

Dear Tunesmiths,

>>: Faré
>: tril

> WWW-
> do you want to have a asymmetric "mirror" system, or can we have
> bidirectional mirroring?  I would like to input to the drastic
> restructuring of the WWW pages.

Sure. The problem is we need a versioning system
that warns maintainers of each other's modifications.
One problem is to allow future integration of this system with TUNES,
so we can get into self-development.

Current versioning system for the 'net include:
* CVS. It's relatively simple and robust,
 but a centralized design and a low-level (C) implementation.
 Very Tunes-unfriendly. Could be an expedient way to get things started, tho.
* Coda. The design is much better (distributed), but the implementation
 is in C, too, and the Linux driver is only in latest 2.1, which are
 rather instable (PPP, PLIP, UMSDOS, etc, are all at least partly broken;
 I don't know how well fs/coda/ works).
 I think we can steal a lot from the design (causal coherency, etc),
 but the implementation would have to be mostly thrown away (just a guess).
* I haven't made a review, so there might be other freely-available tools.

The other option, developping our own tool,
allows for better future integration
through the use high-level languages (such as Perl or GUILE),
as well as customization to our needs.
As for getting things started, the TUNESADM script is
a working skeleton for semi-automatic handling of e-mail patches
as a way to synchronize between developers.

I believe that it pays better to develop our own high-level tools,
make them reliable, and rely on them, than to use ad-hoc low-level tools.
All the more as we move toward WWW pages automatically-generated from source.

As for mirroring packages, here are a few pointers:
http://www.math.uio.no/~janl/w3mir/
http://pobox.com/~maroger/inform/omaweb/
There are plenty other mirroring programs (sup, fmirror, etc),
but again, they are only suited for centralized replication,
which is only meaningful for our FTP and/or email repository.


> E-mail lists-
> I'll handle the tunes lists.  Do you want to mirror these at
> all?  Would you provide search capabilities at sweety, too?

there are currently problems or disk space availability on sweety (www),
to be solved in a few weeks; in the meantime,
sweety can't mirror much anything, so bespin (www2) will have
to stay primary and sole list->WWW handler for some time.


> personal E-mail accounts-
> Shall I handle MX for the entire tunes.org domain?
I'll have to talk with my friends who are sysadms of sweety...

> DNS-
> I can't handle it yet, but after Bespin's upgrade I may be able to
> provide primary/secondary DNS.
We've already got DNS working ok for tunes.org;
I'll remember your offer when it's time to update DNS stuff.


>> The lists could be named
>> 	tunes-announce
>> 	tunes-smiths
>> 	tunes-admin
>> 	tunes-lll
>> or such.
>
> OK, sounds good for now.
> Should we automatically subscribe everybody from "tunes" to announce,
> smiths, and admin?
Hum, maybe we can make a group tunes-discuss for general discussion,
and reserve tunes-smiths to implementation?

> Is the LLL list dead?  Is the latest message really from January, 1997?
Tunes-LLL is dormant. Let it be. No need to kill it, it might wake up soon.
Unless we separate tunes-discuss from tunes-smiths? Dunno.


>> Finally, I am to separate documentation sources,
>> to be made in some language that allows programming,
>> from actual WWW pages in HTML, to be obtained by compiling the former.
>> Are you familiar with any language that could be used here?
>> I've heard of Jade, but never understood the actual details;
>> I still have to figure out where introductory docs lie... any help 
>> anyone?
>
> What do you mean by "programming"?  I think TeX can do whatever it is you
> need.  Why is HTML so bad?  Couldn't you just use a WYSIWYG HTML editor?
>
The problem is that TeX is far too low-level,
and oriented towards typesetting.
I want documentation to be high-level,
and suitable for production of data in many formats, including HTML.

The LDP (Linux Doc Project, to which I participate with the Assembly-HOWTO),
has similar intentions, and currently is using SGML as sources,
and is moving towards such things as DSSSL.

Only, for TUNES I'd like something that allows for more than
document source->output processing;
I want a full-fledged documentation system,
that can gather information from various sources,
and make a collection of cross-referencing output documents.

For instance, it would automatically generate
commented HTML directory listings for Files.html;
it would allow to globally factor information
that is shared accross multiple documents,
such as who's the maintainer, what's a URL to point to him,
what are headers/footers/styles to use for the pages;
it would automatically propagate information from source to documentation
(like Knuth's literate programming),
but also verify consistency of information,
transform it, etc.
It would manage the Glossary as a database,
and allow easy cross-reference to/from it.

Granted, that's all long-term projects;
but I want to move toward that direction,
not trap myself into non-scalable low-level tools.
[BTW, HTML editors are just a joke to me; I use XEmacs].

== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rideau@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System.               | 75019 PARIS     FRANCE
http://www.tunes.org/~tunes/                     -=- Reflection&Cybernethics ==