On Mon, Mar 30, 2009 at 11:41 AM, Rickard Öberg <[email protected]> wrote:
> Hey,
>
> As we have evolved Qi4j a number of libraries, tutorials and extensions have
> been created, to explore what is possible to do, and how to do it. I think
> all of that filled a function, but now that Qi4j is getting more stable I
> would like to do a spring cleaning and remove what is outdated or which we
> don't think we'll get to production quality. This is to get less code to
> maintain, faster builds, and less noise for people looking at the codebase.
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.
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/
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/
:
> * 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.
> * 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.
> * Maybe Amazon S3 EntityStore. I don't think it makes sense to have S3 as a
> primary EntityStore, but maybe as a secondary (i.e. backup). We need to
> think about how to get this to work.
Sandbox it.
> * Swift EntityStore. Niclas, do you want to get this to production quality?
> If not, I think doing the BDB-JE store will fit its purpose of
> high-performance, local store.
Sandbox it.
> To sum it up, for EntityStores I want to focus on the following ones:
> * Neo4j
> * BDB-JE
> * REST
> * Coherence
> * JDBM
> * Memory
Ok.
> * Jini libraries. Niclas, what's the status here? Will this get to
> production quality?
Sandbox it.
> * The Swing binding needs an overhaul and rethink. I'm doing lots of Swing
> work right now, and not much of what is there now makes sense to me.
Kill it. I drastic re-think needed, and current hack too messy to
maintain in long-run.
> * Visualizer. Focus entirely on Envisage for visualization.
Kill it.
> * What is the status of the Struts2 binding? Production quality? If not,
> what's left?
>
> * lib-beans: is this working? Useful?
Sandbox it. Eventually, I want POJO integration to be smoother than it
currently is.
> * lib-business: scrap! (it's empty anyway...)
+1
> * 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?
> * lib-enumeration: what is the idea here? Anything useful?
>
> * lib-exception: I don't think this is particularly useful, compared to just
> using logging and Thread-exception handlers to track exceptions. Opinions?
>
> * lib-executor: scrap
Sandbox it. I want build a "worker/task" system.
> * lib-framework: too generic name and almost empty anyway. scrap!
+1
> * lib-general: lots of domain-specific stuff. Scrap it, and if we want a
> place to put some domain-specific code that can be "reused", then better put
> it in a sample app so that people can copy/paste/adapt it. Domain code is
> always going to depend on the local usecases!
+1
> * 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".
> * lib-quikit: Scrap?
+1, see Edwards note.
> * lib-reqistry: Niclas, what's the idea here? Anything to keep?
Sandbox it.
> * lib-rmi: scrap? Not sure if this is useful, or if it's better to focus on
> e.g. Jini for things like this, if at all
Sandbox it.
> * lib-spring: rename to ext-spring, as it is more of an extension than a
> library.
Agree.
> * lib-thread: scrap?
Sandbox it.
> * lib-transaction: this one should be kept, but we need someone who knows
> transactions to work on it, and I don't. Any takers?
I don't understand it, no opinion. I suggest sandbox it for now.
> * lib-uid: scrap, already exists as helper in SPI
I disagree. I think in that case that the helpers in SPI should be tossed.
> * lib-validation: we *do* need alot of thinking on how to do proper
> validation, but I'm not sure the code in this library is good as it is.
> Needs more thinking
Can sandbox it for now, if you like. I am Ok to keep it in libraries/
> * ddd-sample: scrap and re-import the new 1.1 version as there's a LOT of
> rewriting in it
No opinion.
> * pet-clinic: scrap? This is a CRUD-app which is not very DDD. It *might* be
> ok as a way to show a simple app, but... it's not good practices in it as it
> is
Scrap.
> * sample-helloworld: scrap, in favor of the helloworld tutorials on
> composites
Scrap.
> * tutorial-cargo: scrap or keep? if keep, then it needs to be updated
Well, the idea was to follow the books evolution of the Cargo app. But
this also shows up in dddsample/
We need one or the other, but not both. Converting dddsample/
"step-by-step" is a massive undertaking, but perhaps the best
"real-world" tutorial material we could ever produce.
For now, sandbox it.
> * tutorial-recipe: scrap
Agree.
> In short, keep the intros and the composite+service tutorials, fix the
> Service tutorial to be complete and add one on Entities. Then we should have
> a decent baseline for documentation.
:-) You are choosing the wrong target for "baseline for
documentation". A slowdown of changes to what Qi4j is a lot more
important :-)
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.
> That's about it! I hope noone takes personal offense because of these
> suggestions. There's a LOT in the above that is my own code, I should point
> out. What I'm concerned with is focus and quality. Better have a lot of
> effort on something that is good, rather than a little effort here and there
> on stuff that won't work in the end.
+1. My own crap is a lot about "learning Qi4j" for myself, and see if
it holds water at all.
I also think that Sandboxing is better than tossing things completely.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
