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

[Jean-Francois Leveque]

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

Thanks,
- J-F

Noah Botimer a écrit :
> Jean-Francois,
> 
> Thank you for summarizing this material. I was going to suggest that 
> there has been enough thoughtful exchange here to archive the topic in 
> Confluence.
> 
> 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.
> 
> Thanks,
> -Noah
> 
> 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