[Proposal] New Architecture for XWiki 2.0

Vincent Massol vincent at massol.net
Mon Feb 12 00:07:48 CET 2007


forgot to cc Jason...

-Vincent

On Feb 12, 2007, at 12:06 AM, Vincent Massol wrote:

> Hi XWiki developers,
>
> I'd like to start a discussion on the XWiki 2.0 Architecture. I've  
> put my thoughts on http://www.xwiki.org/xwiki/bin/view/Idea/ 
> ArchitectureV2 (sorry I haven't explained a lot yet so I guess  
> you'll have to be familiar with component-oriented development to  
> understand fully what it means - Do not hesitate to ask questions  
> if there's something not clear :-)). I'm listing down here the  
> content of that page so that we can discuss it here more easily.
>
> I'd also like to start working and experimenting with it. Actually  
> my goal is to do a POC to see what level of changes would need to  
> be brought to the core and more importantly whether or not we can  
> keep the backward compatibility and thus start refactoring in the  
> 1.x code base rather than start a complete new 2.x branch.
>
> In any case I'd like to create a XWIKI_2_0 branch tomorrow for  
> starting the experimentation. In addition Jason Van Zyl (whom I'm  
> cc-ing and who's the creator of Maven, Velocity, Turbine, Plexus  
> and other OSS projects ;-)) is keen to work with us on this and  
> would also like experimenting ASAP. I'm thus proposing to give him  
> write access to that XWIKI_2_0 branch.
>
> Let me know what you think
>
> Thanks
> -Vincent
>
> -----------
>
> 1.1 Ideas
>
> * Component-oriented architecture using a Component Manager
> * Each component group (set of component for implementing a  
> concept) is separated in its own build module and generates a JAR
> * Make the component 100% independent of the Component Manager used
> * Register the Component Manager using a Servlet Context Listener
> * Question: Should we use existing components from the Component  
> Manager implementation? If so the question is whether it'll work  
> with other Component Managers?
>
> 1.1 Implementation Details
>
> * Use Plexus as the Component Manager (each component JAR has a  
> META-INF/components.xml file that configures Plexus)
> * Future: Make the components OSGi-compliant (each component JAR  
> has a META-INF/Manifest with OSGi configuration in there)
> * Start creating a branch in XWiki (xwiki/xwiki/branches/XWIKI_2_0)  
> for working on this.
> * Idea: It would be nice to merge back the work progressively (if  
> possible) on the trunk. It might be possible as we have a public  
> API which we could keep and only change the underlying  
> implementation for now, thus preserving backward compatibility  
> (except possibly for plugin writers but that's less of an issue IMO).
>
> 1.1.1 List of Components Required
>
> * Rendering and Renderers
> * URL Management (Portlet, Servlet, XMLRPC, etc)
> * Storage + Query/Search (JCR, DB/Hibernate, Subversion, etc)
> * Authorization (JAAS, DB, etc)
> * Authentication (JAAS, DB, LDAP, etc)
> * User/Groups Services
> * Document Services
> * Configuration Services (dynamic configs in DB for example)
> * Remote Calls Services (XMLRPC, SOAP, Email, etc)
> * Attachment Services
> * Statistics Services
> * Cache Services
> * Logging
> * Wiki Services (like getWikis() for a farm, etc)
> * Container Services (adaptation layer for Servlet, Portlet, etc)
> * I18N Services
> * Notifier Services (SMTP, IRC, SMS, etc)
>
> Lots of these services should offer extension points so that it's  
> possible to write extensions against them. The idea is to remove  
> the need for a Plugin interface that would list all the possible  
> extension points. Instead it should be each component offering  
> those extension points. Alternatively the extension would  
> completely replace or wrap an existing component.
>
> 1.1 Todos
>
> * Create Architecture diagram listing all components required
> * Define the interface for each component
> * Idea: Start with the Rendering component and the Renderers  
> (Velocity, Radeox, Doxia, etc). Note: We need ordering as a page is  
> going to be rendered in sequence by all the renderers (unless a  
> renderer says not to continue the chaining)
>
>
>


	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com




More information about the devs mailing list