initial commit of thoughts on how to package the services.

1 files changed, 48 insertions, 0 deletions

diff --git a/docs/eazel-services-framwork b/docs/eazel-services-framwork
new file mode 100644
index 000000000..006134dd1
--- /dev/null
+++ b/docs/eazel-services-framwork
@@ -0,0 +1,48 @@
+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.