[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Help, the Cathedral, and the Bazaar
> One acronym: HTML. Develop a web browser, and allow it to use a
> help:// protocol or something like that. Make a browsable help index
> and include some cgi (or java) to allow searching of the
> help database. I don't know. I hope that these are
> good ideas.
I'm not sure I'd want a help browser to have to use network sockets to read
help files. It introduces too many possible problems, i.e. what happens if
you misconfigure your web server? How are you going to read the help files
telling you how to fix it?
I'd prefer to put all the help files on disk and have the help browser load
them directly. If we want to support remote help, fine, but it shouldn't
be the primary method. (remote help might be cool in a NC-ish office
environment where you can't or won't NFS export all the help files, or you
have some random server in Timbuktu that has bandwidth for HTTP, not NFS)
> Take a look at how KDE has structured its help system.
That's something someone needs to do for -dev-help. Exhaustively review
all existing help systems, in a format similar to Donovan's editor review
page. GNOME's upcoming help system, which I'd like to merge with xhelp if
possible (bazaar dictates a throwaway version..), is based on a much faster
and more robust HTML display widget, native Gtk code, which if made
pluggable, along with access method .so's (disk, HTTP, etc.) might make a
very cool system.
> Why not decide on a universal interface standard, which programmers
> should use to develop software for seul? Then, make software which
> follows these standards available from the seul website, and put
> a seul "seal of approval" on them or something?
That's kindof the idea. Commercial apps are the primary target, where we
would provide the libraries, exhaustive documentation, and general
interface specifications to make sure their app fits in with everything
else, and can interoperate.
Again, this is where GNOME comes in. They've already got things almost to
that point. They simply need some larger apps, plus commercial support.
This is where SEUL comes in, getting office apps and commercial vendors to
work within the GNOME framework, as well as helping it to mature into a
full network-object system (as its name implies).
> Since software is GPL'ed, you could have developers who work
> to make sure that applications conform to these standards.
Yup. That's what maintainers are for. Debian uses this method, with a
maintainer for each package. Most maintainers are in contact with the
'upstream' developer (i.e. the author of the package), but I have a feeling
that link isn't utilized to the fullest. There are still patches galore to
put Debian together. I'd like to see those patches generalized, and make
thier way into the *primary* distribution.
The other shortcoming of the Debian mechanism is that packages are not
stored in a central location at all times. Only the resulting packages
make their way to the site, usually, which means that if someone disappears
after changes have been made, but before they make it to the site, they get
lost. SEUL will have a CVS repository containing the *entire*
distribution, and packages will be built automatically, repeatably, by the
system. That gives us more stability, better maintainability, oh, and
version control... ;-)
> Some standard libs for developers wold be a nice idea too.
That's the idea behind the Core/Layers concept. A specification document
defines what the Core and various Layers provide (not how), and a reference
implementation is constructed to provide for the basis of SEUL. My goal is
to eventually standardize the Core/Layers such that commercial developers
can code against the standard and *know* that their app will install and
run on any compliant system. Eventually, other distributions would almost
be forced to be compliant. However, I don't want that to happen, as I
would like other distributions to be involved in the process of writing the
> I do't thin that it's possible to maintain a complete bazaar-like
> atmosphere, and have universal standards. Not unless you own
> every shop in the bazaar.
Right. Though universal standards aren't the goal, necessarily.
Competition is good, and I have little doubt that some distributions may
prefer to go their own way (I won't mention any, you can probably guess).
I do want to make the point that 100% bazaar development isn't going to cut
it for SEUL. There will have to be some structure, else nothing that needs
to get done, will. At the core of bazaar-style development is the belief
that everyone is coding to scratch their own personal itch, be it
technological or philosophical. While this is still the case for SEUL,
either one way or the other depending on the individual coder, there are
just some things that can't be done by general "yeah, I want to do this"
concensus. Standardization (i.e. a consistent interface) is one of those.
We (luka and I) will be continually reviewing our processes, with the goal
of making things work as smoothly as possible. Common sense dictates that
this will be very close to bazaar-style development. I won't tell you that
it'll be 100%, but as close as practical in order to acheive our goal.
Erik Walthinsen <email@example.com> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user