From davidwboswell at yahoo.com  Sun Jul 24 14:13:50 2005
From: davidwboswell at yahoo.com (David Boswell)
Date: Sun Jul 24 16:14:54 2005
Subject: [Multexi] Re: Definition of Tasks: MultExI
In-Reply-To: <42DEC5E9.4070402@northern-tribes.de>
Message-ID: <20050724201350.25546.qmail@web32503.mail.mud.yahoo.com>

Ludwig,

This looks very well thought out.  I'm copying the list on my reply so
other people can comment on this as well.  I'd also suggest posting
this information on your project site.

As far as defining the scope and goals of your project, I think this is
a great document.  As far as providing any technical feedback on what
you propose, I think maybe some of the other people on this list or on
the project_owners@mozdev.org list might have some useful feedback for
you.

Let us know how things are going and let us know if there is anything
we can help you with.

David


> within this message I would like to define a previous version of the 
> definition of efforts for the MultExI project.
> If nessecary, I would define a more detailed document after you 
> acknowledged the defined efforts or after we found a solutions for 
> possible obscurities.
> 
> For the time being I'd like to apologize for any missunderstandings 
> because of my english - just three hours a week english lessons
> aren't 
> very conducive to speak corrent englisch ;)
> 
> 
> So, I'll devide the TODO list into two parts, client (firefox
> extension) 
> and server.
> 
> /**************
>  *     CLIENT     *
> **************/
> The complete client application consists of a common Firefox
> extension. 
> As far as possible the developed extension will reuse already
> existing 
> code (e.g. the Components.interfaces.nsIExtensionManager) and will be
> 
> designed to be reusable too.
> For explaining the functionality of the extension, I'll give a simple
> 
> scenario how the application might be used later:
> 
> [01] - First, of course, the user installs Firefox.
> [02] - He visits the website: http://firefox.my-intranet.com. The
> user 
> will be asked by firefox to install the multexi- extension.
> [03] - When Firefox has restarted after the installation of multexi,
> the 
> user's work has finished.
> 
> (I think this should be the highest aim of the application -
> simplicity. 
> Simplicity and minimal time efforts would get sys admins easier to
> plead 
> for the establishment of Firefox as a system far standart.).
> 
> What follows just happens in background:
> [04] - multexi automatically reads a list of extensions from the
> server 
> where it has been downloaded from. For that, multexi uses the server 
> where it has been downloaded from. This information multexi will get 
> form its own RDF which has been generated by the server application.
> 
> (In version two (after SOC) one could think about if it should be 
> possible to assign extensions to specific groups because a software 
> developer will need other extensions than a secretary).
> 
> [05] - multexi will download and install all defined extensions and -
> 
> depending on its configuration - it will automatically ask the user
> to 
> restart, it forces a restart or it just waits for a restart by the
> user.
> 
> [...]
> 
> [ n] - From now on multexi cyclically checks the list of defined 
> extensions and - if s.th. has changed - multexi would synchronize the
> 
> local installed extensions/settings with the MEDL (Multexi Extension 
> Definition List).
> 
> (Later one could think about that multexi also becomes responsible
> for 
> the update of Firefox itself. I think this would help alot. In my 
> company e.g. all Firefox installations had to be completely removed 
> after the last security issues. This prohibition is still active,
> just 
> because our sys admins are afraid that the user wouldn't update their
> 
> Firefox. Multexi could solve this problem).
> 
> ------- finished ------
> 
> 
> /**************
>  *     SERVER    *
> **************/
> One effort to the server part should be its portability. For that we 
> have to decide about the language to use to. Also we should decide
> which 
> network protocol should be used.
> 
> I think the most simple and effective protocol would be HTTP. HTTP
> gives 
> the possibility of a more or less automatic installation of multexi 
> (CLIENT - [02]).
> I think the one and only alternative would be SOAP. But concerning
> SOAP 
> there's a german proverb which would describe the use of SOAP in this
> 
> conext very good I think: "That is shot with cannons at a sparrow". 
> Which means that the use of SOAP might be very exaggerated.
> Propable HTTP would be the best solution. .... (?)  ;)
> 
> Now we have to decide for a specific programming language. In our 
> decision we should bear in mind the portability and the target group 
> (large networks - probable companies).
> Personally I would tend to an independant C++ or Java/J2EE solution. 
> Java would bring the advantage with it that it is portable and very
> fast 
> to be developed. Unfortunately it is not that efficent. Otherwise 
> companies that are running SAP application servers using 3GB of RAM
> or 
> Oracle databases using the same or more won't be afraid of a 25MB
> Java 
> J2EE deployment. Probably a J2EE Server is already running - than a 
> multexi server written in Java/J2EE won't take much more resources
> than 
> a C++ application. Further more the use of J2EE technology would 
> simplify the process of implementing a web based administration
> system 
> which than could be integrated into a local intranet e.g.
> An alternative to J2EE would be a StandAlone C++ application. I can 
> imagine that Java/J2EE might be rather accepted than C++ - keyword: 
> typical security issues like buffer overflows and so on.
> 
> Currently I'm not sure how to decide.... Any idea? PHP might also be
> a 
> solution - but a very dirty one in my oppinion (*doesn't like PHP*)
> ... :D
> 
> Now to the funcionality of the server:
> 
> + Simple installation routine.
> + Definition of a list of extensions to install (firstly by manual 
> editing a configuration file - l8tr perhaps via a web admin iface).
> + Server automatically provides the multexi extension with
> automatically 
> adjusted rdf (or additional cfg file - would be perhaps the more 
> beautiful way), so that multexi knows where to get the extension list
> from.
> 
> Basically the server provides the following options:
> 
> + Update extension list automatically for new extension versions
> (yes/no)
> + Server should work as cache (proxy) for downloaded extensions
> (yes/no).
> 
> 
> So I think that's enough stuff for the "first time". Because in 5
> hours 
> my night will be over, I'll interrupt this mail at this point.
> Concerning the programming language I did not post to the
> project_owner 
> ng because than again one of these typical basic- discussions might
> be 
> caused which results in nothing. I could imagine that you've got a 
> better overview of how to decide, because you know more about mozilla
> 
> and the community than me. Perhaps you can add some hints or make a 
> suggestion. Otherwise I could also post to project_owners or decide
> it 
> for my self.
> 
> 
> Thank you very much,
> Ludwig :)
>