[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.
Cheers,
Anth
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