Niclas Hedhman wrote:
I agree, when/if the codebase is stable enough to not be a an issue
with Refactoring. I.e. IF we move stuff out, every refactoring
resulting in API changes will need to be pre-announced and discussed.
So, that is the downside.
Yeah, agree.
And to reinforce the "pain", I don't want extensions/ and libraries/
being part of the "Core" project. That way, we have a counter-balance
for an A-team vs B-team. So how about;
projects/qi4j/
api/
spi/
runtime/
bootstrap/
Do you see the tests as also being a part of this? Probably, right?
projects/qi4j-ext/
bdb-je/
jdbm
:
projects/qi4j-lib/
projects/qi4j-tutorials/
projects/qi4j-samples/
projects/qi4j-apps/
chronos/
streamflow/ (?? ;-) )
projects/qi4j-sandbox/
libraries/
extensions/
tutorials/
apps/
:
Looks good to me. The sandbox solves the problem with "fun projects" but
which aren't necessarily recommended.
* The Chronos app. Niclas, do you ever see this being finished? If yes, then
I suggest to move it outside of the Qi4j project. If no, then scrap it. Up
to you.
Let me think about that. In any way, I still think that the structure
above would solve your concerns.
Agree.
* JGroups EntityStore extension. I don't think anyone will ever use this in
production.
Sandbox it. Well, in the current state I would recommend against
production deployment, but it is a stub for people to build upon if it
catchs their fancies.
* RMI EntityStore. I would prefer to focus entirely on the REST entitystore
for remote access.
Sandbox it. REST is of course preferred, but I still want to see
performance data before I am convinced for LAN deployment.
Fair enough.
* lib-cache: caching makes sense in two places I think: data and
computation. Data is already handled by the EntityStores, which leaves
computation, probably in services. Do we want a library for that, or should
this be done by simply using a cache library in the implementation?
Isn't the ESs delegating to this lib?
No, this is not caching on that level. It has more to do with
computation caching, i.e. caching method results based on input parameters.
We might want to do a specific EntityStore caching, for that purpose.
Would be very good to have. I need one right now for StreamFlow REST
EntityStore, on the client side.
* lib-logging: Niclas, do you want to keep this? Status?
Yes, I want to keep it, since it is getting fair close to being
useful, especially after we introduced the "Context Concerns".
Fair enough.
* lib-uid: scrap, already exists as helper in SPI
I disagree. I think in that case that the helpers in SPI should be tossed.
So then basically all projects would have to have a dependency on this
one? Fine by me, just checking.
:-) You are choosing the wrong target for "baseline for
documentation". A slowdown of changes to what Qi4j is a lot more
important :-)
I should have said "baseline for tutorials" :-)
I have not had time for the last 3-4 months to do any documentation,
and in this period we have had a lot of massive new concepts
introduced. Will take a while to catch up on that.
Same here.
I also think that Sandboxing is better than tossing things completely.
Yeah, agree, that makes sense.
Alright, I'll do the suggested killings. Do you want to do the suggested
structure refactoring before 0.7?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
