[xwiki-devs] [Discussion] Make Invitation Application storage and configuration comparable with Invitation Manager plugin.
11 May
2010
11 May
'10
12:34 a.m.
In http://www.mail-archive.com/devs@xwiki.org/msg14717.html
Ludovic said "We need to be as compatible as possible with how the
current invitation manager stores it's configuration and state
(current invitation and requests)"
I think this concept is worthy of it's own discussion thread.
When I approached this project, I hadn't considered a need for an
upgrade path from the Invitation Manager (I assume that's what this
is for.) The application as it stands is quite dependent on a
different configuration/storage model and changing will take a long
time.
Do we really want to use the same configuration/storage as the
Invitation Manager?
* The Invitation Manager plug-in uses configuration parameters
defined in the now deprecated xwiki.cfg file while Invitation
Application uses a custom configuration class through the
XWiki.ConfigurableClass system.
* Invitation Manager and Invitation Application both store message
status as a number, Invitation Application uses additional codes for
"sending failed", "reported as spam", and "reported and
investigated".
* Invitation Manager has an additional field "space" which will make
no sense without Space Manager plug-in in the invitation application
setup and will have to be replaced by "groups".
* To copy Invitation Manager setup will block further feature
addition such as invitations which expire after a given amount of
time (for mailing lists).
* Invitation Manager templates are coded in a format similar to
XWiki/1.0 syntax (but not exactly the same) Invitation Application
templates are (currently) to be coded in XWiki/2.0 syntax.
Options:
We could continue the Invitation Application as is and if an upgrade
path is needed, add a script for upgrading legacy data later on.
Drop the current work and get the Invitation Manager plugin to build
(It would be a shame to dump so much work over one requirement.)
Rewrite the current work to be compatible with the old Invitation
Manager, accept using depricated configuration and sacrifice
features (this will take the most time.)
What are your thoughts?
Caleb
11 May
11 May
12:38 a.m.
New subject: [xwiki-devs] [Discussion] Make Invitation Application storage and configuration comparable with Invitation Manager plugin.
Hi Caleb,
On Tue, May 11, 2010 at 00:34, Caleb James DeLisle <calebdelisle(a)lavabit.com
wrote:
In
http://www.mail-archive.com/devs@xwiki.org/msg14717.html
Ludovic said "We need to be as compatible as possible with how the
current invitation manager stores it's configuration and state
(current invitation and requests)"
I think this concept is worthy of it's own discussion thread.
When I approached this project, I hadn't considered a need for an
upgrade path from the Invitation Manager (I assume that's what this
is for.) The application as it stands is quite dependent on a
different configuration/storage model and changing will take a long
time.
Do we really want to use the same configuration/storage as the
Invitation Manager?
* The Invitation Manager plug-in uses configuration parameters
defined in the now deprecated xwiki.cfg file while Invitation
Application uses a custom configuration class through the
XWiki.ConfigurableClass system.
* Invitation Manager and Invitation Application both store message
status as a number, Invitation Application uses additional codes for
"sending failed", "reported as spam", and "reported and
investigated".
* Invitation Manager has an additional field "space" which will make
no sense without Space Manager plug-in in the invitation application
setup and will have to be replaced by "groups".
* To copy Invitation Manager setup will block further feature
addition such as invitations which expire after a given amount of
time (for mailing lists).
* Invitation Manager templates are coded in a format similar to
XWiki/1.0 syntax (but not exactly the same) Invitation Application
templates are (currently) to be coded in XWiki/2.0 syntax.
Options:
We could continue the Invitation Application as is and if an upgrade
path is needed, add a script for upgrading legacy data later on.
+1 for this (see my reasoning below).
Drop the current work and get the Invitation Manager
plugin to build
(It would be a shame to dump so much work over one requirement.)
I don't think that's a sound idea.
Rewrite the current work to be compatible with the old
Invitation
Manager, accept using depricated configuration and sacrifice
features (this will take the most time.)
A lot of work for little benefit.
What are your thoughts?
I think Ludovic's point of view is affected by the fact that he spent a lot
of time working on Curriki. While I understand and sympathize a lot with it
knowing where it comes from, I also think that you're making a lot of pretty
valid points about why both applications should not necessarily be
compatible. The different syntax, the different model (wiki application
versus plugin), the different feature requirements make it a new application
versus an improvement on the old one.
In any case I'm not sure that even with the improvements you suggested the
application would be usable in Curriki's context. The space and invitation
manager have been tailored very specifically for that project, and while
it's a shame that we're not able to reuse that code, we also have to
acknowledge the fact that the XWiki platform has evolved a (huge) lot since
those plugin were released. This means that more than their code itself,
it's the way how they're architected that pauses the real issue - thus
making them beyond repair.
As for the migration path, as I mentioned it, besides Curriki and the
retired XWiki Workspaces project that plugin is not used anywhere to my
knowledge. Thus I'm not sure what the migration path would look like.
In short, we need to accept that though they share the same name, we're
actually talking about 2 different applications. I'm not happy that we're
sending code to retirement, but it wouldn't be the first time we do it (the
old rendering & WYSIWYG are a good example) and I don't think we've
regretted that.
My 2 cents,
Guillaume
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
10:20 a.m.
New subject: [xwiki-devs] [Discussion] Make Invitation Application storage and configuration comparable with Invitation Manager plugin.
On Tue, May 11, 2010 at 00:34, Caleb James DeLisle <calebdelisle(a)lavabit.com
wrote:
In
http://www.mail-archive.com/devs@xwiki.org/msg14717.html
Ludovic said "We need to be as compatible as possible with how the
current invitation manager stores it's configuration and state
(current invitation and requests)"
I think this concept is worthy of it's own discussion thread.
When I approached this project, I hadn't considered a need for an
upgrade path from the Invitation Manager (I assume that's what this
is for.) The application as it stands is quite dependent on a
different configuration/storage model and changing will take a long
time.
Do we really want to use the same configuration/storage as the
Invitation Manager?
* The Invitation Manager plug-in uses configuration parameters
defined in the now deprecated xwiki.cfg file while Invitation
Application uses a custom configuration class through the
XWiki.ConfigurableClass system.
* Invitation Manager and Invitation Application both store message
status as a number, Invitation Application uses additional codes for
"sending failed", "reported as spam", and "reported and
investigated".
* Invitation Manager has an additional field "space" which will make
no sense without Space Manager plug-in in the invitation application
setup and will have to be replaced by "groups".
* To copy Invitation Manager setup will block further feature
addition such as invitations which expire after a given amount of
time (for mailing lists).
* Invitation Manager templates are coded in a format similar to
XWiki/1.0 syntax (but not exactly the same) Invitation Application
templates are (currently) to be coded in XWiki/2.0 syntax.
Options:
We could continue the Invitation Application as is and if an upgrade
path is needed, add a script for upgrading legacy data later on.
+1
Drop the current work and get the Invitation Manager plugin to build
(It would be a shame to dump so much work over one requirement.)
-10
Rewrite the current work to be compatible with the old Invitation
Manager, accept using depricated configuration and sacrifice
features (this will take the most time.)
-1
What are your thoughts?
Invitation Manager is pretty old style and it would be a shame to not follow
new clean standards.
It's not like invitation manager was part of standard XE...
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
5242
days inactive
5243
days old
2 comments
3 participants
participants (3)
-
Caleb James DeLisle -
Guillaume Lerouge -
Thomas Mortagne