On Jun 25, 2008, at 1:00 AM, Artem Melentyev wrote:
Hi, Vincent. Sorry for late reply.
Vincent Massol wrote:
It seems like you're transforming current storage code into components. I'm not sure what important advantages this brings. What I'd like to see is to have new code and new apis use components but I'm not sure about old code. Maybe you could explain what's your plan?
The plan is in proposal "Componentize XWiki Stores" http://xwiki.markmail.org/message/vs7wbfjv7ipyz2t3 and XWIKI-2443 I don't see anything wrong in components in old code.
No you're right there's nothing wrong with that. I initially thought it was just an effort that wouldn't be worth it since it would need to be done again when we move to the new interfaces. However I see you're using that to solve an issue with sharing some Hibernate factories so that's fine to me.
Do you plan to create clean interfaces for storage?
not yet. I just want to refactor old storage system for easy support of many storage implementation. Current store system contains too many code duplication (business code, manipulate with model) for different storage implementations. And I want to separate simple DAO components (which can be used as prototype for new storage components) from old stores to resolve it.
ok so this is an intermediary step between what we have and the "clean" components I guess.
If so this really needs to be discussed and proposed on the devs list with a design page on xwiki.org.
However this probably requires a prerequisite of having the new model in place before it can be started? wdyt?
Yes for new storage component.
So the question I have is: should I completely rewrite storage system (+ new model) from scratch just for add a good jcr storage :) or can I just refactor old one?
This is a good and valid question. I think you're doing right and since this JCR implementation is needed sooner rather than later and since we're missing the prerequisites (new model) I think it's best to overhaul the current JCR implementation using the old API but providing an easy migration path for later on (which is what you're doing I think).
New storage is better of course. But it requires so much work, especially on new model. When new data model is planed?
I think we should restart the discussion this summer so that we all agree on the model. Then the implementation shouldn't be too hard since I think we can have the 2 models cohabit. I need to finish the new rendering foundations (then I'll need other committers help to rewrite the macros - I wish we could find a macro framework in Java with lots of existing macros but I doubt it). Thanks Artem -Vincent