16 Dec
2010
16 Dec
'10
9:01 a.m.
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