On 12/16/2010 03:01 AM, Vincent Massol wrote: > 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. These are only used by Hibernate and the packaging plugin. They are for serializing the attachment archive as a byte array so it can be stored or exported. Since the filesystem implementation will be storing each attachment as a separate file, there is no analog. I believe this is sufficiently internal that we need not offer an upgrade path.
> >> 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. I favor evolution over revolution not only for the obvious reason that it is available "now" but because it allows changes to be tested immedietly. God forbid we invest in 20k lines of code and when finished we find it "looked good on paper" but simply does not work. > 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). I am also envisioning a new storage engine based on the TransactionRunnable class which is currently housed inside of FilesystemAttachmentStore. However, I want to experience the challenges of using TransactionRunnable in the real world before I start proposing any interfaces which use it. > > 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. +1 Caleb > > </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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
