[Management] Configuration in Sakai 2 (was Re: [Building Sakai] What do you think about Config Viewer?)
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
On Jan 8, 2010, at 5:59 AM, Jean-Francois Leveque <jean-francois.leveque at upmc.fr
> 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
> 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
> - 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
> - 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
> 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?
> Jean-Francois Leveque
> management mailing list
> management at collab.sakaiproject.org
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
More information about the management