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

[csev]

On Aug 31, 2010, at 10:42 PM, Steve Swinsburg wrote:

> Hi Chuck,
> 
> 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.

Your choice of words do not inspire confidence :) - they reinforce my perception that EB solves some problems nicely but only supporting access through EB is not sufficient for important data.

> 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 am not talking so much about whether we render in-server or in-browser - I am happy for folks to experiment with in-browser rendering like Roster in tools that don't see a million clicks per day so we gain experience in the pattern over time without betting the whole farm on it.    And EB/direct is a solid solution for providing access to DAOa and other data for this pattern of programming.

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

Imagine that in 2.9, I wanted to add a little display to every portal page that indicated how many of your "profile2 friends" were on line and if you clicked on it a little window would slide up and let you chat with them (uh, like Facebook perhaps).

That means that portal needs to compute the "number of online friends" for the logged in user for every portal view.   It would not be satisfactory if the portal had to do a REST call to /direct to get that information.   Whatever call that the portal will do millions of times per day needs to be highly tunable with sweet caching, and maximally efficient all the way down to and through the DAO to the most efficient query possible.

The way to keep that kind of activity both "arms length" and "maximally tunable" is the API/IMPL/Service pattern.

Like I said earlier, I do want my cake and to eat it too.   And to be clear - this is not thinly veiled opposition to profile2.  Forward progress is good.

/Chuck