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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
