As a step toward shedding some of the architectural cruft in Mulgara, I would like to propose a new application starting point. Most of the innards will be reused (!LocalSessionFactory, XANodePoolFactory, etc.), but they will be exposed in a modern component setting. I propose the Spring Framework as the component model with the most momentum and chance for synchronicity with other activities. In addition to all of the Dependency Injection and Inversion of Control yumminess, Spring AOP supports proxy-based AOP and Spring 2 supports AspectJ syntax and byte-code weaving, both of which could help us modularize system concerns to be reusable and flexible.
There are also all kinds of related projects which will help us out in the long run including:
- Spring MVC WebApps
- WebFlow Workflows, replacing the Webui infrastructure
- Acegi a declarative security model for integration with external auth/auth systems
- XFire a modern, high-performance WebServices stack
Additionally, Spring is moving toward a decent integration with OSGi which would open up some interesting future capabilities for Mulgara.
Paul has expressed concern about this being a diversion from some of the under-the-hood work. I think the efforts are orthogonal, and can thus proceed in parallel, but I think modernizing the architecture is going to be key to making Mulgara usable by different systems, languages, etc. This is also of importance to me for some of the projects I am integrating Mulgara into.
I consider this architectural refactoring mostly component integration. I don't want to break anything or prevent some of the other work from moving forward, so I will leave EmbeddedMulgaraServer alone. This should allow both dev efforts to move forward together toward a common future rendezvous.
original page by Brian Sletten
I'm guessing that you'd like to provide a query module in NetKernel which can resolve URIs containing queries into a set of results.
I note that NetKernel caches results from previous queries so that a URI will always return in the same result. That actually works under RDF, because RDF is never supposed to change. My concern is that Mulgara has INSERT and DELETE operations. How do you think we'd handle this? Or am I thinking about the problem incorrectly?
original comment by Paul Gearon