Re: SEUL: WWW site issues

[Erik Walthinsen <omega@omegacs.net>]

> First, what minimum browser spec are we designing to? For instance, we
> could have a rule of "everything must be readable by XXX". XXX being,
> for instance, Lynx or Netscape 2. This is not to say that there can be
> no tags not recognised by the minimum browser (eg font sizes), just that
> someone using this minimum must not loose any content.
That is an issue we have to deal with.  There are several ways to do it, 
with increasing reliance on proc power and software on the server side.  
The current site has been designed to look as good as possible in Lynx, 
while retaining its presentation under Netscape.  If you look at the code, 
you'll find that the ALT tags for the sections are tied to dummy images, 
not the actual graphics.  This allows Lynx to show the section titles 
before the text, rather than after.

If we want to be truly browser independent, we'll have to make sure that 
all the docs that have some kind of specific presentation are served by 
some kind of cgi-bin program.  The parser arma wrote, combined with a good 
set of handlers based on what I've written, could be optimized and used to 
server/cache pages for appropriate browsers, possibly running as a Fast-CGI 
program or other setup.  However, the more we rely on these things, the 
less likely it is we'll find sites willing to mirror for us.

> In the longer term: This is not very relevant at present, but eventually
> I can envisage two almost separate sites being required: one for
> development and one for potential users investigating SEUL.
> At some point I think the two sites will have to separate, with the
> users' one being www.seul.org and containing a link to the dev site
> (maybe seul.org/dev) for anyone interested.
We've thought about how to keep them separate enough, and I think we have a 
decent method:

1) all files in specific public_html parts of the CVS repo will be checked 
out into a given place, tagged for en masse revision control, and will be 
designed to provide the end-user site.
2) files placed into html/ subdirectories *anywhere* in the repo will be 
checked out sans the 'html/' part, and should be designed for the end-user 
site
3) files placed into doc/ subdirectories, again *anywhere* will be checked 
out into the website, and can contain whatever you like.  This is so that 
docs for various packages (ours or someone elses) will always be available 
on the web.

(see http://www.omegacs.net/~omega/seul/dirhier for examples)

This doesn't address the issue of separation between church and state, er, 
developers and end-users, though.  I don't know if there's a good way to 
enforce that, but I think as long as we define what is end-user and what's 
developer, we'll be OK.

One way to do it is to assume that html/ stuff is *always* for the 
end-users, and anything in doc/ is for developers.  There's nothing keeping 
html and sdoc files out of doc/, so it can be used for anything.  For 
instance, dev/ui/doc/index.html might be the developer homepage for the 
user interface group, even though dev/help/xhelp/doc/README is part of the 
xhelp distribution and is raw text.  (I hope that made sense... :)

This does need to be discussed, however.

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user