[Deploying Sakai] [Management] Configuration in Sakai 2 (was Re: [Building Sakai] What do you think about Config Viewer?)

Noah Botimer botimer at umich.edu
Fri Jan 8 03:39:55 PST 2010


Thank you for summarizing this material. I was going to suggest that  
there has been enough thoughtful exchange here to archive the topic in  

It is probably also worth scoping out two or three levels of project  
and asking again for levels of interest in them. I would like for us  
to not lose your original question, which I take as a call for  
involvement on the Config Viewer and consideration of it as a project  
going into incubation with aspirations of moving forward in our newly  
refined product development process.

One final detail is that this should all be considered in relation to  
the Maintenance Team. There are lots of properties related to code  
that seems to match up with the eventual MT scope. We should not set  
accidental expectations on a young group, whatever work is undertaken.

As a personal opinion, I think that most of our work these days should  
be examined for items that apply in the Sakai 3 context. Not  
everything overlaps but it is always valuable to ask the question.

Also, at the risk of being pedantic, my paticipation in this  
conversation has been as an individual. I make no claim that my  
contribution represents a Product Council opinion. My involvement  
there should have no bearing on how this conversation is read. If the  
PC forms an opinion, it will be as a group and communicated explicitly  
as such.


On Jan 8, 2010, at 5:59 AM, Jean-Francois Leveque <jean-francois.leveque at upmc.fr 
 > wrote:

> It seems lots of things are wished for. I wonder whether we can do all
> for 2.8 or not.
> I don't know anything about Sakai 3 configuration but this input might
> be useful.
> The only member of the product council we got input from so far is  
> Noah.
> I'm adding this mail to the management list in case managers and other
> members of the product council might want to contribute to the debate.
> Here is a try to summarize and contribute further.
> Properties :
> - Categorize settings [I suggest tool with option of multiple tools]
> - Differentiate settings: Dynamic or Startup (propagation may be  
> difficult)
> - Document settings with valid data types/ranges:
>   - new tool.properties file deployed per tool and/or centralized
> (extension of tool registration's tools.xml or config tool)
>   - Document Startup properties via annotations
> - Keep tools bean properties names as is
> - Use tool registration id as prefix for tool properties
> - Define base name for non-tool properties (like portal)
> - Define base name for cross-tool properties [I suggest shared]
> Configuration mechanism:
> - Consider http://commons.apache.org/configuration/
> - Log update of Dynamic properties
> - Provide cluster-wide propagation
> - Add a control panel (only place for overriding properties)
>   - collapsible tree by category
>   - some settings not editable or viewable (flags: hidden, read only)
> [I suggest default read only for Startup properties and default hidden
> for properties some of us put in security.properties]
>   - differentiate live changes from static configuration
>   - [I suggest adding volatile live changes if the default is  
> persistent]
> - Listener mecanism
> - Authoritative configuration through Dynamic property (statics
> sakai/local/security/placeholder?, persistence of live changes?)
> How do we document the non-tool and cross-tool properties?
> Do we all agree database authority should only work on dynamic  
> properties?
> I may have missed or misunderstood things. Feel free to correct me
> and/or contribute further.
> The next question is who will work on this?
> Cheers,
> Jean-Francois Leveque
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

More information about the production mailing list