[Management] Configuration in Sakai 2 (was Re: [Building Sakai] What do you think about Config Viewer?)
jean-francois.leveque at upmc.fr
Fri Jan 8 05:12:13 PST 2010
+1 for Confluence
I think all those that have contributed have the same general target.
It's obvious Config Viewer and Editor have inspired us a lot and we all
should thank Tony for this. I don't think he would mind how much of his
code will still be used in Sakai 2.8 or later. I think we can't say for
sure if we will build the future config features from Config
Viewer/Editor or not. If changes we need are in parts of the code
maintained by the maintenance team, I think the config team should
submit changes for maintenance team approval like any other fix contributor.
We still have to maintain Config Viewer for Sakai 2.6 and 2.7. I hope we
can still find volunteers for this. If the powers that be decide the
Maintenance Team should work on this even if it's not an official tool,
I would thank them.
I don't think anyone thought you represented the Council. I thought it
was good to have a member of the Council involved in this discussion,
whatever the Council decides later.
Noah Botimer a écrit :
> 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
>> - 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
>> 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
More information about the management