[sakai2-tcc] More Indie Thinking on Profile2 / Profile

[csev]

On Aug 30, 2010, at 9:47 PM, Steve Swinsburg wrote:

> Can you use the Entity Providers to get the data from Profile2 or do you explicitly need the Java API's? 
> 
> I'm thinking that splitting application up will make it harder to perform releases as if any backend work happens in Profile2 (as it almost always does between releases), then both Common and the Profile2 tool need to be released and makes it harder for people to upgrade.  It will also break the easy upgrade path that the indie releases provide - update the version in the pom, deploy, done.
> 
> Common has historically contained complete services and hasn't left tools (that are being worked on) dangling.
> 
> Interesting discussion though if others have any input.
> 
> cheers,
> Steve


On Aug 30, 2010, at 9:49 PM, Aaron Zeckoski wrote:

> Bear in mind that you can access EB data via Java or REST so if you
> need to grab profile data which has providers then you can directly
> get it in Java if you want to. You can also use the REST calls if you
> outside Sakai but when you are inside it makes the most sense to use
> the Java calls in the EntityBroker service.
> 
> Just wanted to mention it in case that wasn't clear.
> -AZ

I guess that I had hopes that in time the profile2 data would become more "core" and less the property of a tool.

If we are going to start treating profile data like core, we should have an API and a contract and it should live in common so other core code can depend on the contract and be informed (in the form of syntax errors) when the contract changes.

For something to be core, we need predictable performance and not a lot of maps of strings being created and uncreated every time we grab a list of friends.

Don't get me wrong, EB is cool stuff to mash up a bit of PHP - or serve up the data to a third party system and also cool when there is a need for once-in-a-while loose interaction between tools functioning as peers or if someone hacks up a bit of JQuery in the browser to update some floating status thing - very cool and lots of fun.

But when something is core and cross-cutting, I would prefer to see the profile2 DAOs and core interfaces moved to common and cleaned up as a contract and then in the profile2 tool, layer EB on top of that agreed-to and internally used API.  I would like other tools to be able to access the profile2 data in as rich and detailed a fashion as the P2 tool itself.   For example, does the profile2 tool access its own data through EB?   What I want is that other tools can have the high-contract access to the P2 data as the p2 tool has to "its own" data.

In a sense, if what you are saying is that the contract between profile2 and the rest of the system is on a "lots of change" vector, I am a little concerned - but I also understand - but if you are changing the contract,  EB does not make dealing with changes in data model and contract any easier - EB actually makes it harder (bordering on virtually impossible) to detect a model change because of the loose coupling.

I know that tight and loose coupling each have advantages and disadvantages.  For something as important as profile2's data - I want to have my cake and eat it too.

Perhaps, profile2 will follow the pattern that Grade Book followed where it started as a silo and then kind of exported a "contract" in edu-services.  A couple of observations: (1) the GradeBook service in edu-commons is just sufficient to to little things - you could not use it effectively to write a whole gradebook tool, (2) the API barely feels "designed" - as folks needed something they put it in, and (3) I shudder to think about interacting with the GB exclusively through EB in terms of performance and long-term code reliability if they had taken the "we will export our data to the rest of the system through EB" approach.

in summary, since I have no time to write the code I hope to see, I have to accept the fact that I will be less than happy with the approach you have taken and if EB is the only way to talk to your data and in the next version, I need to talk to profile2 data - I am stuck with EB.

The alternative of no forward progress is far less attractive.  These are problems that perhaps we can address in time.

/Chuck