Re: [eclipse-dev] Initial User Settings document

["Michael Valenta" <Michael_Valenta@xxxxxxxxxx>]

Jeff,

Please see my comments below.

Jeff McAffer/Ottawa/IBM@IBMCA Sent by: eclipse-dev-admin@xxxxxxxxxxx 18/06/2003 11:06 PM Please respond to eclipse-dev

To:        eclipse-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [eclipse-dev] Initial User Settings document

This is great capture of usecases and scenarios.  Clearly user settings
is one of those areas that looks simple but turns out to be very problematic.
 I don't have much to add in the way of scenarios but do have some
thoughts on the store... 

- you mention an interest using XML values to support more than primitives.
 Does this imply that you expect any part of the settings mechanism
to interpret the values it manages?  To what end?  This would
essentially mean unmarshalling the objects encoded in the XML and may prove
to be quite difficult (unless you are spec'ing a marshaling DTD in which
case, your crazy! :-).  I would suggest just storing strings.  If
the string happened to be XML then whoever accesses the value can parse/unmarshal
it. 

MV>>First, I should mention that I'm not saying
that all settings should be XML (although it was written that way in the
doc). Only those settings that are not primitive data structures should
be XML. Also, it was not my intention to use the XML to allow interpretation
of the settings by the settings mechanism (although I must admit that the
idea did cross my mind;-). My intention was to provide setting values that
could be understood by visual inspection. There has two compelling arguments
for this. For one, in the absence of proper tooling, this is the only avenue
that ISVs have to tailor settings. One could argue that we should create
proper tooling but my feeling is that creating proper tooling will be the
most difficult part of this problem. A good fallback position is settings
files that can be edited manually (and, as we all know, editing information
that is on a single line in a string is not easy). The other reason involves
reconciling changes to settings files that are being merged by a user.
I know that this may not be an achievable goal even with XML but if the
entire setting is on a single line it cannot even be considered.

Your point about a DTD is a good one. Is it a requirment
to have a DTD when marshalling XML? I know that it is desirable but the
reality is that XML is written and read in many places without a DTD. If
this is a requirement, then we either need to drop XML (which, IMHO, limits
what we can accomplish but may be the way we go) or pursue the use of DTDs
(which implies that I may be crazy;-). 

- by unified settings store it is unclear if you mean that all settings
would be stored in one store or that there will be one store mechanism
and any given running Eclipse will be using several store instances for
the differently scoped settings.  I am assuming/hoping for the latter.


MV>>The later, of course;-) My intention was to
have one mechanism that manages where the settings are stored an how a
setting's value in Ecipse was determined.The storage location for a particular
setting would be determined using several factors (setting scope, is the
setting local or sharable, where does the user want settings to be stored,
etc.). My hope was that, given the unified mechanism, we could play around
with various storgae schemes.

- It may be interesting to allows others to supply implementations for
the stores in various scopes.  In some enterprise scenarios for example,
application preferences would be stored on a central server/database.  This
may also help in controling sharing in the sense that the store for a particular
scope of setting can dictate whether or not the settings in that scope
are shared. 

MV>>Good idea. We'll add it to the pot.

- Applications will have some security concerns wrt settings.  It
is unclear if you actually have to do anything.  On the one hand you
could say that the setting mechanism has security and people have to have
the right permissions etc.  On the other you can just say that it
is insecure and people who store valuable info there should encode it properly
to prevent tampering.  The former is more work for you, the latter
puts the work on the consumers.  Either way a security statement should
be made. 

MV>>Agreed

- As an aside, OSGi (http://osgi.org) has a "user preference service"
with a relatively simple store API .  Basically a hierarchical tree
of keys/values(with primitive types I think).  As it is a service,
the implementation is not specified or implied.  You might look at
it when designing your store API. 

MV>>Thanks for the pointer. I'll hav a look.

Jeff

Michael Valenta/Ottawa/IBM@IBMCA Sent by: eclipse-dev-admin@xxxxxxxxxxx 06/17/2003 12:06 PM Please respond to eclipse-dev

To:        platform-core-dev@xxxxxxxxxxx, eclipse-dev@xxxxxxxxxxx        cc:                Subject:        [eclipse-dev] Initial User Settings document

The initial document describing user settings problem has been posted at
the following URL: 

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/docs/online/team3.0/settings.html

The term "user settings" can mean different things to different
people so the first goal is to ensure all of the relevant scenarios are
documented. If you know of a scenario that is not covered, please let me
know either by annotating the bug report (https://bugs.eclipse.org/bugs/show_bug.cgi?id=36965)
or posting on the platform-core-dev mailing list (I have cross-posted to
eclipse-dev because of the broad nature of the problem). Also, a first
cut at defining a solution is also included so feel free to comment on
that as well. 

Michael Valenta