Re: Sakai 2.2 changes

Glenn R. Golden wrote:

> So to fix this ONCE AND FOR EVER (cause while I love the new API  
> names, after 3 re-orgs, a 4th won't surprise me down the road), I'm  
> introducing the idea of an "application  id", which is a string that  
> WILL NOT CHANGE, and is most specifically NOT an API full path name.

You're right about code changing and evolving.  It's always a safe bet.  
So switching to APPLICATION_IDs is a good idea.  However, why call it an 
application id?  Doesn't this apply to components across the board?  
Isn't it confusing to called it an application id when it largely 
identifies services?  I think COMPONENT_ID might be a better term, if I 
understand the matter correctly.

> A Reference's getType() will return the APPLICATION_ID of the  
> application that owns the entity being referenced.

This is something that I don't agree with.  How do you see an 
APPLICATION_ID (which is really a component identifier) as a type?  If 
getType() is always implemented to return the application id, it should 
be called getApplicationId() or getComponentId(), and documented as 
such.  Sakai is already full of mis-named methods.  The code should 
evolve to make things MORE obvious, not less.

- Mark Norton

----------------------
This automatic notification message was sent by Sakai Collab 
(http://collab.sakaiproject.org/portal) from the DG: Development site.
You can modify how you receive notifications at My Workspace > Preferences.