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

Anthony Whyte arwhyte at umich.edu
Fri Jan 8 05:47:09 PST 2010

Given that Config viewer is a contrib tool it falls outside the  
Maintenance Team's zone of responsibility (e.g., unsupported/weakly  
supported Sakai core projects).

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



On Jan 8, 2010, at 8:12 AM, Jean-Francois Leveque wrote:

> +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
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

More information about the production mailing list