Hi Caleb, On Tue, May 11, 2010 at 00:34, Caleb James DeLisle <[email protected] > wrote:
> In http://www.mail-archive.com/[email protected]/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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
