Hi Dan, That would seem to make sense. My only concern is stability / continuity. Could you make it switchable / pluggable so that we can mostly use the new runtime but fall-back to old if necessary?
Best Regards Mike ( iPhone) On 27 Feb 2011, at 15:58, Dan Haywood <[email protected]> wrote: > Hi all, > > Over the last month or two I've been working through our various modules, > ostensibly to work on their documentation. As part of this I've been using > Structure 101 [1] to detangle the packages structures and make it easier for > would-be contributors to understand the codebase. So far I've tidied up > core.common, core.metamodel and core.progmodel. I'm now up to working on the > core.runtime module... and it needs quite a lot of work. > > What I'm actively considering is to write a new runtime, so that our current > runtime moves out of core and into (say) org.apache.isis.runtimes.dflt. This > new runtime could be a lot more lightweight than the current, because we > could use other frameworks to do some of the heavy lifting that our current > runtime does. Specifically: > - context management of scopes (application/session/transaction) - ie the > IsisContext class - could be managed by JSR-299 CDI (this is our roadmap > anyway to implement, [2]) > - rather than invent our own ObjectStore API to abstract over different > persistence implementations, we could leverage DataNucleus (as suggested in > ISIS-14, [3]) > > I think this would be less work overall than tidying up our current runtime. > We could also more thoroughly test-drive the new implementation. > > My thoughts is that the existing object stores would be moved so that they > live "under" the existing runtime. The same is true (I think) for the > bytecode implementations and also the remoting support. > > However, the security and progmodel APIs, and also the viewers, live in the > application layer (ie in "front of" the runtime) and so would be usable by > both the existing and the new runtimes. This may require a little > refactoring to remove dependencies on IsisContext; but I think refactoring > these classes would be relatively straightforward. > > ~~~ > I have, therefore, added a page to our wiki [4] suggesting a new directory > structure and groupId/artifactId. I'm happy (as usual) to make these > changes; but I don't want to charge in there without some discussion. > > If we do this work, what I'll do is to fully document core, and but only > lightly document the existing runtime, on the basis that there'll be a new > runtime to follow. > > Thoughts? > > Cheers > Dan > > [1] http://www.headwaysoftware.com/products/structure101/index.php > [2] http://wiki.apache.org/incubator/IsisProposal > [3] https://issues.apache.org/jira/browse/ISIS-14 > [4] > https://cwiki.apache.org/confluence/display/ISIS/MavenModulesMultipleRuntimesProposal >
