[Building Sakai] Entity Broker Future - In Kernel / Main SVN

[csev]

On Nov 25, 2010, at 1:49 PM, Stephen Marquard wrote:

> If we want to "evolve EB forward" then we specifically should NOT move
> it into the kernel, to facilitate more frequent releases.

Steven - the definition of the "kernel" is based on how core the functionality is to Sakai - not how frozen the code is.   When I say "evolve" - I mean very slow, gentle changes based on use cases identified as we apply EB to many of the legacy portions of Sakai.  I think EB is mostly feature complete and any changes will be adding a bit of flexibility here and there to allow for new use cases.

> The only real reason to put something into the kernel is to simplify
> the dependency tree, or if we want kernel code to depend on it. Is this
> the case here?

I do want parts of the kernel to be comfortable depending on EB Registry (like Site for example).  I could imagine some of the kernel legacy services starting to be re-written one at a time to use GenericDAO instead of DbDouble and that series of the original ORM utilities that underpins many of the legacy services.

But more importantly, I want a very clear signal that EB Registry and GenericDAO are part of the core of Sakai that is maintained by the kernel team for the general good of the Sakai community.  In a sense, one of the goals of moving it into the kernel is to remove the "indie" label - both in terms of release processes and architectural direction of EB. 

There are also some "yucky" bits like the core providers that are an artifact of EB being an indie and all of it in one jar.  The site providers should be part of Site - not part of EB's "core" - but until we move EB into kernel, we need to keep things incorrectly factored to avoid introducing dependencies in the wrong direction.  Once EB moves into Kernel - these can easily be moved to the right place and things will look much cleaner.

As we move forward with things like LessonBuilder aggregating tools and (perhaps) a wall tool aggregating notifications, we need something to consistently underpin our cross-tool communication (including legacy tools) and EntityBroker is a good solution to those problems - but it is a bit unnerving for a good fraction of the developer community to build software that depends on something that is kind of "glued on the side" - rather than "in the core".

/Chuck