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

[Anthony Whyte]

> 
> 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?


Below is a list of all (indies-included) 2x projects in trunk with a direct dependency on entitybroker (see below) that are targeted for the 2.9 release.  I've not checked Sakai core projects for transitive dependencies on entitybroker but they certainly exist .  Projects that depend on entitybroker have transitive dependencies on Aaron's generic-dao and reflectutils projects.  Chuck mentions including generic-dao but reflectutils should also be included in the discussion.

I imagine that adding entitybroker, generic-dao and reflectutils to the kernel would simplify the dependency tree but so too would adding a number of other projects (no advocacy here).  In my view, simplifying the dependency tree is not a sufficient condition for kernel inclusion--a necessary condition perhaps, but not a sufficient one. 

> 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. 


Likewise, dropping something into the kernel in order to send a message to the community about a project's value is not a sufficient condition for kernel inclusion.  After all, plenty of projects/services are considered "core" without being part of the kernel.

> 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".


I think the above statement a more compelling argument for entitybroker inclusion in the kernel; i.e., that it provides a common, low-level service for facilitating data exchange across tool boundaries (and perhaps within the kernel itself) that core and contrib developers regularly rely upon.  

Active 2x core projects, particularly indies, utilize entitybroker's interface and utilities.  2x projects under maintenance so far do not but that is largely a function of scare developer resources than to any conscious decision to forgo using the entitybroker for communicating across tool boundaries.  While reliance on entitybroker is by no means pervasive more projects depend directly on entitybroker than on either common or edu-services, two intermediate service packages.  If more tools received the entitybroker treatment it would rapidly become ubiquitous within Sakai.  

If entitybroker is the way to exchange data between tools (and active project teams appear to have made it so of late) then it makes sense to investigate moving it into the kernel.  I say investigate as I think a proof-of-concept is in order before actual trunk commits occur.

Cheers,

Anth


EB DEPENDENCIES

/announcement/announcement-tool/tool/pom.xml:      <artifactId>entitybroker-api</artifactId>
/announcement/announcement-tool/tool/pom.xml:      <artifactId>entitybroker-utils</artifactId>
/assignment/assignment-api/api/pom.xml:      <artifactId>entitybroker-api</artifactId>
/assignment/assignment-bundles/announcement-tool/tool/pom.xml:      <artifactId>entitybroker-api</artifactId>
/assignment/assignment-bundles/announcement-tool/tool/pom.xml:      <artifactId>entitybroker-utils</artifactId>
/assignment/assignment-impl/impl/pom.xml:      <artifactId>entitybroker-api</artifactId>
/assignment/assignment-tool/tool/pom.xml:      <artifactId>entitybroker-api</artifactId>
/basiclti/basiclti-blis/pom.xml:      		<artifactId>entitybroker-api</artifactId>
/basiclti/basiclti-blis/pom.xml:      		<artifactId>entitybroker-utils</artifactId>
/basiclti/basiclti-common/pom.xml:                <artifactId>entitybroker-api</artifactId>
/basiclti/basiclti-common/pom.xml:                <artifactId>entitybroker-utils</artifactId>
/basiclti/basiclti-portlet/pom.xml:      		<artifactId>entitybroker-api</artifactId>
/basiclti/basiclti-portlet/pom.xml:      		<artifactId>entitybroker-utils</artifactId>
/basiclti/pom.xml:      			<artifactId>entitybroker-utils</artifactId>
/chat/chat-impl/impl/pom.xml:      <artifactId>entitybroker-api</artifactId>
/emailtemplateservice/impl/logic/pom.xml:            <artifactId>entitybroker-api</artifactId>
/emailtemplateservice/tool/pom.xml:            <artifactId>entitybroker-api</artifactId>
/gradebook/app/ui/pom.xml:      <artifactId>entitybroker-api</artifactId>
/msgcntr/messageforums-api/pom.xml:			<artifactId>entitybroker-api</artifactId>
/msgcntr/messageforums-app/pom.xml:			<artifactId>entitybroker-api</artifactId>
/msgcntr/messageforums-component-impl/pom.xml:      <artifactId>entitybroker-api</artifactId>
/osp/matrix/api/pom.xml:      <artifactId>entitybroker-api</artifactId>
/osp/matrix/api-impl/pom.xml:      <artifactId>entitybroker-api</artifactId>
/osp/matrix/tool/pom.xml:      <artifactId>entitybroker-api</artifactId>
/polls/impl/pom.xml:            <artifactId>entitybroker-api</artifactId>
/polls/tool/pom.xml:            <artifactId>entitybroker-api</artifactId>
/polls/tool/pom.xml:            <artifactId>entitybroker-utils</artifactId>
/profile2/api/pom.xml:    		<artifactId>entitybroker-api</artifactId>
/profile2/impl/pom.xml:      		<artifactId>entitybroker-api</artifactId>
/profile2/tool/pom.xml:      		<artifactId>entitybroker-api</artifactId>
/profile2/tool/pom.xml:      		<artifactId>entitybroker-utils</artifactId>
/reset-pass/account-validator-api/pom.xml:      	<artifactId>entitybroker-api</artifactId>
/reset-pass/account-validator-impl/pom.xml:			<artifactId>entitybroker-api</artifactId>
/reset-pass/account-validator-tool/pom.xml:        <artifactId>entitybroker-api</artifactId>
/reset-pass/account-validator-tool/pom.xml:        <artifactId>entitybroker-utils</artifactId>
/reset-pass/pom.xml:                <artifactId>entitybroker-utils</artifactId>
/rsf-sakairsf/pom.xml:         <artifactId>entitybroker-api</artifactId>
/samigo/samigo-api/pom.xml:			<artifactId>entitybroker-api</artifactId>
/samigo/samigo-app/pom.xml:            <artifactId>entitybroker-api</artifactId>
/samigo/samigo-services/pom.xml:            <artifactId>entitybroker-api</artifactId>
/search/pom.xml:                <artifactId>entitybroker-utils</artifactId>
/search/search-impl/impl/pom.xml:        <artifactId>entitybroker-api</artifactId>
/search/search-impl/impl/pom.xml:        <artifactId>entitybroker-utils</artifactId>
/shortenedurl/api/pom.xml:      		<artifactId>entitybroker-api</artifactId>
/shortenedurl/impl/pom.xml:      		<artifactId>entitybroker-api</artifactId>
/site-manage/site-manage-participant-helper/pom.xml:      <artifactId>entitybroker-api</artifactId>
/sitestats/sitestats-impl/pom.xml:      <artifactId>entitybroker-api</artifactId>
/user/user-tool-prefs/tool/pom.xml:		<artifactId>entitybroker-api</artifactId>
/user/user-tool-prefs/tool/pom.xml:		<artifactId>entitybroker-utils</artifactId>


/master/pom.xml:                <artifactId>entitybroker-assembly</artifactId>
/master/pom.xml:                <artifactId>entitybroker-api</artifactId>
/master/pom.xml:                <artifactId>entitybroker-utils</artifactId>
/purepoms/sakai-standard-tool/pom.xml: <artifactId>entitybroker-api</artifactId>


On Nov 25, 2010, at 2:37 PM, csev wrote:

> 
> 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
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20101129/26cf8f6c/attachment.bin