26 Mar
2008
26 Mar
'08
10:40 a.m.
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.
26 Mar
26 Mar
10:54 a.m.
+1
On Wed, Mar 26, 2008 at 10:40 AM, Jerome Velociter <jerome(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
--
Jean-Vincent Drean
11 a.m.
+1
On Wed, Mar 26, 2008 at 10:40 AM, Jerome Velociter <jerome(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
11:14 a.m.
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.
12:06 p.m.
New subject: [xwiki-devs] [VOTE] Integrate activitystream plugin in platform-plugins/
Hi Jerome,
On Mar 26, 2008, at 10:40 AM, Jerome Velociter wrote:
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
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?
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
28 Mar
28 Mar
2:34 p.m.
On Mar 26, 2008, at 12:06 PM, Jerome Velociter wrote:
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
Hi Jerome,
On Mar 26, 2008, at 10:40 AM, Jerome Velociter wrote:
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
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?
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 ?
6114
days inactive
6116
days old
5 comments
4 participants
participants (4)
-
Jean-Vincent Drean -
Jerome Velociter -
Thomas Mortagne -
Vincent Massol