[DotGNU]SEE architecture

[S11001001]

Here I have posted a HACKING file I wrote. I have just started 
structuring one. No actual code yet, but lots of frustration with autotools.

Get the full story at http://www.geocities.com/pitabasic/dotgnu/see.tar.gz

HACKING:

At first, the directory naming might be confusing. I thought of the
names as the code support for whatever the SEE was communicating with;
for example, at first sight, SEE-server should contain the code for
serving webservices. However, it really contains the code for clients
to access SEEs offering webservices, because in that case, the object
on the other end of the communication is a SEE-server.

If you need a better explanation, think about the server. Wouldn't it
make sense for it to keep a bunch of different "Client" objects
around? I extended this principle to the directories, so I could more
easily keep the class structure in mind.

Each directory also has its own namespace.

Here's what's in the directories:

doc: Documentation. I generate code documentation with Doxygen;
anything else is in Texinfo.

misc: URL parser, preferences parser, and general networking.

user-client: Support for users being clients; that is, running
programs.

SEE-client: server support; providing webservices and such.

plugin-client: running plugins; provides the plugin API with
information.

plugin-API: library used by plugins to access SEE information through
pipes.

running-API: library to connect directly to a local SEE. seerun is
also built here.

SEE-server: Accessing another SEE to get webservices.

SEE-sibling: Code for the root SEE to pass webservice requests to the
proper sub-SEEs.

SEE-older-brother: Communication with the root SEE for webservice
access.

platform: platform-specific code. No #ifdefs for platforms, available
functions, etc., should go in any other directory.

startup: main function, handles messy init junk. All the convenience
libs in the other directories are finally linked here.

Stuff that hackers shouldn't be too concerned with:

config: my AC_CONFIG_AUX_DIR.

Some people might say that it's a good idea to provide an option to
remove SEE-client and such for users, or SEE-server for SEEs that only
serve. However, I don't want people to get in the habit of just
ignoring the fact that they can download webservices and run them
themselves; if they have to `recompile' (scary), then it will be as if
they never had that ability. SEE puts service providers and users on a
more equal footing than traditional server-client models.

I've basically just written stubs and put TODOs in them describing
what the class must do. Please look at these for work.

************************************************************************

HACKING: quick overview of the code structure in SEE.
Copyright (C) 2002  Stephen Compall.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

--
Stephen Compall
DotGNU `Contributor' -- http://www.dotgnu.org

There has been another attempt to seize power. So far, the
aristocratic forces have been defeated.
        -- Radio Free OZ