Raphael Luta wrote:
> Hello,
>
> Now that I have a decent network connection again, I'll commit the bunch of changes
> I've done over the week-end once I've catched up with my real work...
>
> Here are a list of modifications :
>
> Services:
> =========
> I've created a couple of services.
> What I have ready:
>
> * EngineContext
> This is the EngineContext service written by Jeff in which I removed all
> obsolete code.
>
> * PortletCache
> This service is an adaptation of the PortletCache system. I removed the dependency on
> the Cocoon MemoryStore and used instead the TurbineGloablCache service as a backend.
> As it is, the PortletCache is mainly used for bridging the old caching semantics of
> Jetspeed and the TurbineGlobalCache semantics. It'll need to be modified when the
> caching semantics will be refactored.
> I had to remove the MemoryStorePortlet functionality because the GlobalCache does not
> currently support monitor operations. It would be a good thing to add it and send the
> patches to the Turbine list.
>
> * URLManager
> This started as a port of the BadURLManager code but morphed into a new service. The
> idea behind the idea is : why have a service that only deal with bad urls when you
>can
> have a service that deal with any URL and affects them a status ?
> So the URLManager is just that: a central clearing house for registering URLs and
>their
> status (which can be extended to also store their next update date, caching status,
> etc...).
> Since this require a lot of change in JetspeedDiskCache and associated classes which
> Santiago is working on, I currently only use it to emulate the BadURLManager behavior
> (ie store only the bad URLs).
> It's fairly untested because I did not have a real internet connection for testing
> during the week-end so it may take a few days to make it work well but it doesn't
> break the basic operation of Jetspeed. If you find bugs in it, please send patches.
>
The idea is good. The whole idea of having a ResourceManager goes along the same lines.
feeddaemon, badurlmanager and diskcache are our simple implementations of this manager.
> So that leaves the following services to write urgently to completely remove the
> use of the JetspeedServlet:
> * registry
> * daemon
> * cocoon
>
> I'll tackle Cocoon next. Registry and Daemons may require more thought because they
> aren't singletons.
>
> Architecture
> ============
>
> I've changed a little the src package architecture and remove some unused classes.
> Mainly I renamed the 'turbine' package to 'modules' in order to match the standard
> Turbine naming conventions.
> This means that the 'localization' subpackage should certainly move because it's not
> a 'module' in the Turbine sense but I'm not sure yet where these classes should
> belong.
See below: turbine.localization, if it is related to turbine modules, or
jetspeed.localization if it is abstract.
>
>
> Speaking about package organisation, I think the target architecture should be
> something like:
>
> jetspeed
> modules/
> screens/
> navigations/
> layouts/
> localization/ ???
> om/
> portal/ (portal object model: Portlet, PortletSet, etc...)
> peer/ (Persitense dependant implementations)
> syndication/ (syndcation object model: URLInfo, etc...)
> peer/ (Persitense dependant implementations)
> services/
> profiler/ (layout)
> capability/ (layout)
> portletcache/ (layout)
> cocoon/ (layout/templating)
> xsl/ (layout/templating)
> urlmanager/ (syndication/CMS)
> diskcache/ (syndication/CMS)
> feeddaemon/ (syndication)
> contentdaemon/ (CMS)
> castor/ (persistence, Object Relational model)
>
I thought that the portlet API (interfaces) would go into org.apache.portlet, and then
the
implementation under org.apache.jetspeed.portal (or something similar). In this way, we
distinguish between the (I hope abstract) Portlet API and our buggy and dirty
implementation of it :-)
Also, I prefer that turbine modules would go into a turbine.modules package, to stress
that
there we store the glue between Jetspeed and Turbine. If we had alternate
implementations
of the Portlet API (for instance, for pure XML portlets, or for Stream oriented
portlets)
they would go into different packages. Also, we could use turbine.rundata for our
extensions of RunData, ParameterParser, etc.
My two cents (Eurocents, of course) :-).
>
> Does that make sense for everybody ?
>
> --
> Rapha�l Luta - [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
