Massive reorganization of components/services. All service components

        are now broken up into a command-line and a nautilus-view.  Added
        directories for trilobite, the core service framework.  Added
        directories for the proof of concept time sync service.  Also added
        nautilus-installer directory at the base level of nautilus which will
        contain the bootstrap installer for nautilus and its dependancies. Most
        these changes are in the build harness yet.

1 files changed, 0 insertions, 148 deletions

diff --git a/docs/eazel-services-framework b/docs/eazel-services-framework
deleted file mode 100644
index 6d98c9c52..000000000
--- a/docs/eazel-services-framework
+++ /dev/null
@@ -1,148 +0,0 @@
-Nautilus Services Framework thoughts
-Eskil Olsen (eskil@eazel.com)
-May 2000
-
-Nautilus Services packaging :
-
-Packages
---------
-Two base packages:
-	eazel-services
-	nautilus
-
-we should keep the seperate services in seperate packages, that way
-people can install the service they actually want, and loose the rest.
-
-package eazel-services
-----------------------
-should contain the IDL specs for the toplevel interface(s), and the
-shared functions eg. for authentication for root access.
-
-package nautilus
-----------------
-
-the nautilus fm itself
-
--
-
-Then if we keep each service in its own package (two a piece), we'll
-get
-
-timeservice:
-	eazel-service-time
-	nautilus-eazel-service-time-view
-
-where eazel-service-time should contain the corba object plus the
-command line thingy. nautilus-eazel-service-time-view should contain
-the relevant nautilus components.
-
-In this way, people can install just the cli tools and skip the
-graphical tool. The tradeoff is the vast number of rpms, it'll be just
-a minumum for 4 for having just nautilus and one service.On the other
-hand, you can install naughtyloos with just 1 rpm and not have too
-much superfluous stuff, and that you can install the services (cli
-versions only) without all the gui stuff.  
-
-Another benefit is the ability to update the individual services
-without too much download.
-
-The alternative is keeping one gigantic rpm with nautilus and all the
-eazel services. Here the downsides are massive downloads when updating
-even small parts, lack of ability to only install the parts you want.
-The upside is, fewer packages to confuse the user.
-
-
-
-
-Nautilus Services source directory structure :
-
-eazel-services
---------------
-/			the standard automake hell
-/idl			the idl for the toplevel eazel service object
-/libnautilusservices	the shared lib with some common methods (like prompting for root access)
-
-eazel-service-time
-------------------
-/			the standard automake hell
-/idl			the idl for the service
-/src			the corba object and the cli tool
-
-nautilus-eazel-service-time-view
---------------------------------
-/			the standard automake hell
-/src			the nautilus view component
-
-
-
-Naming :
-
-the idl files
--------------
-
-to avoid the impending namespace conflict that the $prefix/gnome/idl
-system will cause, the idl files should be named uniquely:
-
-	top idl file		nautilus-service.idl
-	service specific idl 	nautilus-<company>-<name>-service.idl
-			eg. nautilus-eazel-time-service.idl
-
-IDL interfaces && modules
--------------------------
-
-There is already a module Nautilus, in which we could place the
-Service interface (note, this does not have to be done in the same
-file as the existing Nautilus module is defined). This could also be
-encapsulated as a module within the Nautilus module.
-
-Alternatively, we could make a module specifically for the
-services. This would cut down on the long variablenames.
-
-So something like this for the toplevel
-
-module Nautilus {
-	interface Service {
-		... toplevel calls ...
-	};	
-};
-
-The time service (nautilus-eazel-time-service.idl) :
-
-module Nautilus {
-	module Eazel {
-		interface Time : Service {
-			...
-		};
-};
-
-The time service (nautilus-eazel-install-service.idl) :
-
-module Nautilus {
-	Module Eazel {
-		interface Installer : Nautilus::Service {	
-			...
-		};
-	};
-};
-
-So the scheme for service IDL's would be 
-
-module Nautilus {
-	module <CompanyName> {
-		interface <ServiceName> : Nautilus::Service {
-		};
-	};
-};
-
-
-
-The Shared Library :
-
-
-Contents
---------
-
-The shared library should contain methods that many of the services
-will need. This is quite unspecified currently, but eg call to check
-for distribution type, root access, query/cache for root password and
-such should go here.