Hi Caleb, On Dec 16, 2010, at 6:42 AM, Caleb James DeLisle wrote:
I would like to deprecate the following methods because they insert and remove content which is dependent on JRCS for parsing and generation: XWikiAttachmentArchive#getArchive() XWikiAttachmentArchive#getArchive(XWikiContext) XWikiAttachmentArchive#setArchive(byte[]) These are not easily removed because they are needed for the packaging plugin but I think we should move away from that means of import/export as it contains code (including JRCS) which is memory inefficient.
+1 but if you deprecate you also need to explain by what it is replaced.
Also in the 3.0 cycle, I would like to make private the following methods from XWikiHibernateStore as they are not used externally and are currently deprecated: loadXWikiProperty saveXWikiClass loadXWikiClass loadAttachmentList saveAttachmentList saveAttachment injectCustomMappingsInSessionFactory injectInSessionFactory isValidCustomMapping
+0, I don't know enough the impact so my +0 is an ok in principle if it doesn't break anything known.
I would like to remove the following methods entirely as they are also deprecated and are not used at all: getBatcherStats resetBatcherStats deleteXWikiClass saveXWikiClassProperty
Same as above: +0, I don't know enough the impact so my +0 is an ok in principle if it doesn't break anything known. <future design> I see you're going the evolution way rather than the revolution way. This is good to make progress. In some not too far future I'd like that we introduce a new xwiki-storage module with clean interface and based on components. The Model classes (Document, Wiki, Space, etc) would have the calls to save/load/update/delete and would call this storage module to perform the actual storage actions. This module would offer generic interfaces and an implementation based on Hibernate (in a separate xwiki-storage-hibernate module) and allow to have other implementations (JCR, etc). Note: I had wondered for a long time if we should use directly the JCR api instead of having our own storage API (since JCR provides one) but in the end I think it's better to have our own since it doesn't tie us to JCR and since JCR is not a massive adoption success it's probably safest. </future design> Have you been working on this too or do you plan to? Thanks -Vincent