[xwiki-devs] [VOTE] Integrate activitystream plugin in platform-plugins/
Hello devs, I propose we integrate the activitystream plugin developed for the curriki product the into platform plugins. The plugin provides a notification rule that records doc changes events into dedicated tables in the db, methods to retrieve such events (on a per space basis, or per user basis) + methods to get RSS feeds from those streams. The plugin is not curriki-specific, and provides a "framework" to implement product-specific streams. (see currikiactivitystream plugin as a example). Steps I'm planning to take to integrate the plugin : - Rename its packages (to match XWiki naming strategy) - Write javadoc for it/apply checkstyle - Document its use on code.xwiki.org Here is my +1 to do this. (Note: a goal behind this move is also being able to use the plugin in XWiki Workspaces). Jerome.
+1 On Wed, Mar 26, 2008 at 10:40 AM, Jerome Velociter <[email protected]> wrote:
Hello devs,
I propose we integrate the activitystream plugin developed for the curriki product the into platform plugins. The plugin provides a notification rule that records doc changes events into dedicated tables in the db, methods to retrieve such events (on a per space basis, or per user basis) + methods to get RSS feeds from those streams. The plugin is not curriki-specific, and provides a "framework" to implement product-specific streams. (see currikiactivitystream plugin as a example).
Steps I'm planning to take to integrate the plugin : - Rename its packages (to match XWiki naming strategy) - Write javadoc for it/apply checkstyle - Document its use on code.xwiki.org
Here is my +1 to do this.
(Note: a goal behind this move is also being able to use the plugin in XWiki Workspaces).
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- -- Jean-Vincent Drean
+1 On Wed, Mar 26, 2008 at 10:40 AM, Jerome Velociter <[email protected]> wrote:
Hello devs,
I propose we integrate the activitystream plugin developed for the curriki product the into platform plugins. The plugin provides a notification rule that records doc changes events into dedicated tables in the db, methods to retrieve such events (on a per space basis, or per user basis) + methods to get RSS feeds from those streams. The plugin is not curriki-specific, and provides a "framework" to implement product-specific streams. (see currikiactivitystream plugin as a example).
Steps I'm planning to take to integrate the plugin : - Rename its packages (to match XWiki naming strategy) - Write javadoc for it/apply checkstyle - Document its use on code.xwiki.org
Here is my +1 to do this.
(Note: a goal behind this move is also being able to use the plugin in XWiki Workspaces).
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Jerome, On Mar 26, 2008, at 10:40 AM, Jerome Velociter wrote:
Hello devs,
I propose we integrate the activitystream plugin developed for the curriki product the into platform plugins. The plugin provides a notification rule that records doc changes events into dedicated tables in the db, methods to retrieve such events (on a per space basis, or per user basis) + methods to get RSS feeds from those streams. The plugin is not curriki-specific, and provides a "framework" to implement product-specific streams. (see currikiactivitystream plugin as a example).
Steps I'm planning to take to integrate the plugin : - Rename its packages (to match XWiki naming strategy) - Write javadoc for it/apply checkstyle - Document its use on code.xwiki.org
Here is my +1 to do this.
I'm voting -1 for now just because I'd like more information. For example how does the plugin create new database tables? Does it mean it has its own Hibernate mapping file? This is the first time we're having a plugin modify the database schema and thus we need to decide if we want to allow this and how we want to integrate it in the overall architecture. Right now all storage methods were located in the Storage API. What happens for example if someone changes the xwiki storage class so that storage is not done in Hibernate anymore but in JCR? Thanks -Vincent
(Note: a goal behind this move is also being able to use the plugin in XWiki Workspaces).
Jerome.
Hi Jerome,
On Mar 26, 2008, at 10:40 AM, Jerome Velociter wrote:
Hello devs,
I propose we integrate the activitystream plugin developed for the curriki product the into platform plugins. The plugin provides a notification rule that records doc changes events into dedicated tables in the db, methods to retrieve such events (on a per space basis, or per user basis) + methods to get RSS feeds from those streams. The plugin is not curriki-specific, and provides a "framework" to implement product-specific streams. (see currikiactivitystream plugin as a example).
Steps I'm planning to take to integrate the plugin : - Rename its packages (to match XWiki naming strategy) - Write javadoc for it/apply checkstyle - Document its use on code.xwiki.org
Here is my +1 to do this.
I'm voting -1 for now just because I'd like more information.
For example how does the plugin create new database tables? Does it mean it has its own Hibernate mapping file?
Indeed, I forgot to mention that. The plugin has its own mapping activitystream.hbm.xml, packaged in the jar. My idea about this is the following: - For a standalone use of the plugin, one will edit hibernate.cfg.xml as it will be described in the plugin installation doc. - For a use in a product, I want to propose the idea of having a placeholder in the hibernate.cfg.xml.vm template for extra mappings, like $xwikiDbHbmExtraMappings
This is the first time we're having a plugin modify the database schema and thus we need to decide if we want to allow this and how we want to integrate it in the overall architecture. Right now all storage methods were located in the Storage API.
What happens for example if someone changes the xwiki storage class so that storage is not done in Hibernate anymore but in JCR?
Considering we don't have an infrastructure to handle that, a solution could be the plugin exposing a storage interface for its data, so that it's possible for who needs to implement it. wdyt ? Jerome.
Thanks -Vincent
(Note: a goal behind this move is also being able to use the plugin in XWiki Workspaces).
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mar 26, 2008, at 12:06 PM, Jerome Velociter wrote:
Hi Jerome,
On Mar 26, 2008, at 10:40 AM, Jerome Velociter wrote:
Hello devs,
I propose we integrate the activitystream plugin developed for the curriki product the into platform plugins. The plugin provides a notification rule that records doc changes events into dedicated tables in the db, methods to retrieve such events (on a per space basis, or per user basis) + methods to get RSS feeds from those streams. The plugin is not curriki-specific, and provides a "framework" to implement product-specific streams. (see currikiactivitystream plugin as a example).
Steps I'm planning to take to integrate the plugin : - Rename its packages (to match XWiki naming strategy) - Write javadoc for it/apply checkstyle - Document its use on code.xwiki.org
Here is my +1 to do this.
I'm voting -1 for now just because I'd like more information.
For example how does the plugin create new database tables? Does it mean it has its own Hibernate mapping file?
Indeed, I forgot to mention that. The plugin has its own mapping activitystream.hbm.xml, packaged in the jar. My idea about this is the following: - For a standalone use of the plugin, one will edit hibernate.cfg.xml as it will be described in the plugin installation doc. - For a use in a product, I want to propose the idea of having a placeholder in the hibernate.cfg.xml.vm template for extra mappings, like $xwikiDbHbmExtraMappings
This is the first time we're having a plugin modify the database schema and thus we need to decide if we want to allow this and how we want to integrate it in the overall architecture. Right now all storage methods were located in the Storage API.
What happens for example if someone changes the xwiki storage class so that storage is not done in Hibernate anymore but in JCR?
Considering we don't have an infrastructure to handle that, a solution could be the plugin exposing a storage interface for its data, so that it's possible for who needs to implement it.
wdyt ?
ok thanks for the explanations. I think we need to continue thinking about this and how we want to do it in the new architecture. For now I'm changing my -1 to +1 so that you can progress on the XWS release. Thanks -Vincent
participants (4)
-
Jean-Vincent Drean -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol