Michael Hunger wrote:
That's kind of what you discussed for the streamflow persistence
architecture. So it will be moved to qi4j, even better.
Yes, and even more interesting, from what I can see right now all the
server components are generic! All the domain logic is in the REST
clients. Whether these are remote clients or web server clients
providing webapps is another matter, but the basic infrastructure should
be generalizable and packageable.
Really nice writeup.
I like it very much. What we have to keep an eye on is caching /
providing snapshots because of performance penalties when reading too
many changes. So we should add a number of performance tests to assure
it doesn't get out of control.
Agree.
Perhaps some support from scm methodology for merging changes really
fast would be helpful.
What plans do you have on implementing that? In a local branch of your
own? What about the current ES changes you just finished, will you still
provide those or are they now obsolete?
I have already committed a lot of the changes I made, but have now begun
tweaking that again to implement some of what I have described.
Perhaps you can / should post this to some other place (ddd-mailing
list?) to get some feedback from other guys (greg young etc) on the pros
and cons of this architecture.
Maybe just on the blog, and then post that on whatever lists make sense?
I like it as it makes my ChangeLogES implementation I did in September
obsolete and is of course much much better.
Could you perhaps provide a nice draw up of the big picture for people
to discuss?
A whiteboard pic outlining all the components? Should be possible, yes.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
