dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]SEE architecture


From: Barry Fitzgerald
Subject: Re: [DotGNU]SEE architecture
Date: Sun, 02 Jun 2002 11:59:55 -0400

I would suggest that anyone looking into SEE check out IBM's Sash
environment (Sash for windows: http://sash.alphaworks.ibm.com ... 
SashXB for GNU/Linux:
http://oss.software.ibm.com/developerworks/opensource/sashxb/ )...

Sash for windows is (unfortunately) proprietary but SashXB (for
GNU/Linux only at this point) is available under the LGPL.  I only link
to Sash for windows because it's more mature and better represents what
I'm about to speak about.

SEE is very similar to the Sash Weblication Manager in many ways.  The
manager acts as a runtime unifier for the various different languages
that Sash uses (JavaScript, HTML, XML...) and also handles local
environment sandboxing, file and registry access.  It also catalogs
installed weblications and offers an interface for modifying their
security privileges, not to mention uninstallation of the weblications. 
It's really a very nice technology.  I stumbled onto it almost by
accident a few monthes ago and have been researching it ever since.

So, look into Sash -- you may find something there that you like.

        -Barry



S11001001 wrote:
> 
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]