You make a good point about not touching anything. I agree totally about not modifying the behavior of storage without a configuration switch but to not modify the code at all has a few other consequences.
1. xwiki-core is serving a dual purpose, it is the client of all the services provided by the modules and it is the grave yard for dead and deprecated code. I would like the idea much better if we could usher the dead code from xwiki-core to another module so that core of the application is not the dead code cemetery. 2. The point about custom storage implementations could be applied to any old code, any line we change might be breaking someone who depends on it, this is especially true because groovy allows access to private fields and methods without even a warning. >From the community standpoint, people who make patch sets and keep them secret >are harming the community by keeping their (potentially very good) modifications to themselves, this is the same discussion which goes on with the Linux kernel and closed source modules, I agree with Linus here that although we should not try to stop this practice we should also not protect it by preserving internal APIs. The approach I have thus far taken has been to remove unused code, implement APIs externally, and move things over one at a time. This gives us results right away and makes xwiki-core less bloated but it leaves behind sub-optimal APIs which still need to be rewritten again and introduces more bugs since every interface is at some point reimplemented. Your method (as I understand it) is to rewrite things in large chunks but (at least with rendering) never to break the old API. Reimplementing storage this way would mean we need the thing to store (XWikiDocument) and the objects and properties which amounts to a total rewrite of core before the first result comes in. If we are to keep deprecated code such as rendering1.0 (forever?) I think we need to move it out of the core where it confuses attempts to fix core bugs. Caleb On 02/09/2011 09:21 AM, Vincent Massol wrote: > +0 for the idea but I don't know that part of the code enough to know what > problems this is going to cause (custom storage implementations out there, > etc). > > Personally I'd have preferred to not touch a single bit at any existing > storage interfaces and instead introduce new storage APIs in the new > xwiki-store module and have a flag to direct to the old or new > implementations. This is basically the strategy we followed with the new > rendering engine and that has allowed us to keep 100% backward compat for the > XWiki 1.0 syntax. > > Thanks > -Vincent > > On Feb 9, 2011, at 2:20 PM, Caleb James DeLisle wrote: > >> I would like to propose another round of storage deprecations, the goal of >> these is to remove and >> decrease visibility of code in order to simplify storage and move as much as >> possible over from API >> to implementation details. I am proposing deprecation of each of the >> following, after 2 releases >> this may be revisited and they may be removed or altered. The following are >> changes I have made >> locally and found xwiki-core does compile and test with those changes. >> For now I propose adding deprecation comments and annotations to each class >> or method. >> >> WDYT? >> >> Caleb >> >> >> XWikiAttachmentStoreInterface.java >> saveAttachmentContent(XWikiAttachment attachment, XWikiContext context, >> boolean bTransaction) >> remove >> >> cleanUp(XWikiContext context) >> remove >> >> XWikiBatcher.java >> remove entirely >> >> XWikiBatcherFactory.java >> remove entirely >> >> XWikiBatcherStats.java >> remove entirely >> >> XWikiDefaultStore.java >> remove entirely >> >> XWikiHibernateBaseStore.java >> getDatabaseProductName(XWikiContext context) >> public --> protected >> >> shutdownHibernate(XWikiContext context) >> remove >> >> updateSchema(XWikiContext context) >> public --> private >> >> getSchemaFromWikiName(String wikiName, DatabaseProduct databaseProduct, >> XWikiContext context) >> protected --> private >> >> getSchemaFromWikiName(XWikiContext context) >> protected --> private >> >> getSchemaUpdateScript(Configuration config, XWikiContext context) >> public --> private >> >> updateSchema(String[] createSQL, XWikiContext context) >> public --> private >> >> updateSchema(BaseClass bclass, XWikiContext context) >> remove >> >> isVirtual(XWikiContext context) >> public --> protected >> >> beginTransaction(SessionFactory sfactory, XWikiContext context) >> public --> protected >> >> beginTransaction(SessionFactory sfactory, boolean withTransaction, >> XWikiContext context) >> public --> protected >> >> endTransaction(XWikiContext context, boolean commit, boolean >> withTransaction) >> public --> protected >> >> execute(XWikiContext context, boolean bTransaction, boolean doCommit, >> HibernateCallback<T> cb) >> public --> private >> >> XWikiHibernateStore.java >> getContent(XWikiDocument doc, StringBuffer buf) >> remove >> >> public List search(Query query, int nb, int start, XWikiContext context) >> remove >> >> injectCustomMappingsInSessionFactory(BaseClass bclass, XWikiContext context) >> public --> private >> >> injectCustomMappingsInSessionFactory(XWikiContext context) >> public --> private >> >> XWikiHibernateVersioningStore.java >> loadAllRCSNodeInfo(XWikiContext context, final long id, boolean >> bTransaction) >> protected --> private > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
