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

[Steve Swinsburg]

Hi Chuck,

At the moment, the backend of Profile2 is changing/evolving a lot. It's not impossible to separate them out, I just don't want to do it now because it will add a level of complexity to releases at this point in time. So I don't want to dismiss your idea, rather revisit it down the track when it has settled down. I've provided the EntityProviders to buffer people from the change, and Lancaster are using it successfully for a number of tools, even though everything else changes behind the scenes.

I do think though, that the whole point of Entity Broker going forward was precisely for what you want. It reduces inter tool dependencies (even though the API would be in common) and somewhat protects the end user from API change.

Sure, existing tools don't use it and need the Java API, but new tools certainly could use EB, and they would be lightweight as they are all Javascript based. New tools coming out that use EB almost exclusively for data access: BigBlueButton, updated Roster, YAFT, updated Blog. I was never a fan of the Javascript idea at first, but have warmed to it and now most of my frontend development is all Javascript based. Profile2 still uses it's own APIs and uses Wicket on the front end but could be given a make over easily enough.

I'm not sure what you mean about 'predictable performance' though, is something not working properly? I'm in the process of adding caching to a lot of data which should speed things up dramatically.

cheers,
Steve


On 01/09/2010, at 12:15 PM, csev wrote:

> 
> 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
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3689 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100901/8526fe50/attachment.bin