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