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 would suggest that the following are removed in their entirety:
* 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.
* JGroups EntityStore extension. I don't think anyone will ever use this
in production.
* RMI EntityStore. I would prefer to focus entirely on the REST
entitystore for remote access.
* 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.
* 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.
To sum it up, for EntityStores I want to focus on the following ones:
* Neo4j
* BDB-JE
* REST
* Coherence
* JDBM
* Memory
* Jini libraries. Niclas, what's the status here? Will this get to
production quality?
* 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.
* Visualizer. Focus entirely on Envisage for visualization.
* What is the status of the Struts2 binding? Production quality? If not,
what's left?
* lib-beans: is this working? Useful?
* lib-business: scrap! (it's empty anyway...)
* 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?
* 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
* lib-framework: too generic name and almost empty anyway. scrap!
* 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!
* lib-logging: Niclas, do you want to keep this? Status?
* lib-quikit: Scrap?
* lib-reqistry: Niclas, what's the idea here? Anything to keep?
* 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
* lib-spring: rename to ext-spring, as it is more of an extension than a
library.
* lib-thread: scrap?
* lib-transaction: this one should be kept, but we need someone who
knows transactions to work on it, and I don't. Any takers?
* lib-uid: scrap, already exists as helper in SPI
* 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
* ddd-sample: scrap and re-import the new 1.1 version as there's a LOT
of rewriting in it
* 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
* sample-helloworld: scrap, in favor of the helloworld tutorials on
composites
* tutorial-cargo: scrap or keep? if keep, then it needs to be updated
* tutorial-recipe: scrap
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.
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.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
