10 Feb
2011
10 Feb
'11
4:04 p.m.
On Thu, Feb 10, 2011 at 15:53, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
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.
Note that there is xwiki-legacy project and aspect in xwiki-core to
remove deprecated code from project or java files we want to cleanup.
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:
--
Thomas Mortagne
+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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs