[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]SEE architecture
From: |
Myrddian |
Subject: |
Re: [DotGNU]SEE architecture |
Date: |
Fri, 31 May 2002 09:17:58 +1000 |
User-agent: |
Mutt/1.3.28i |
*he he* I was originally taking care of SEE before I "disappeared", I am
just recently trying to catch up on what's been going on regarding this
project, if it's worth my time to try and design it
or if it's been designed already.
I think I wrote a small document regarding what SEE should and should
not do, it's my personal belief that SEE is not intended to act as
a server to remote web services, it was more of a Jailing Daemon.
Well if you want to talk to me further about it, or let me know about
what's been going on with SEE E-mail me or talk to me on IRC
Myrddian
> 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
>
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers