Re: [ide-dev] EclipseCon Meeting to discuss LDAP-based preference manage

[Carsten Reckord <reckord@xxxxxxxx>]

Hi all,

Since I can't be present for this meeting, I'd like to take the opportunity
to add some thoughts on the topic here.

We are interested in this idea because maintaining personal preferences
across workspaces is a challenge with the current preference story. This is
an important issue for us, that we've already put some work into.
Additionally, the problem of sensible preference defaults and how our
defaults reflect on the IDE and overall user experience has come up multiple
times on this list in the past.

In our own work, we've so far identified a couple of key challenges:

1. Scope

Beyond managing "simple" preferences, there are a lot of other settings,
e.g. view layout. This might involve storing more complex configuration
files or even larger blobs of data. Is this in the scope of this proposal -
now or later? Because in my experience, LDAP often doesn't handle large
unstructured values too well. What do you think, Denis?

2. Preference Meta-data (or lack thereof)

Currently, there is a lot of implicit data about specific preference keys
hidden only in the code dealing with those preferences. This is problematic
when dealing with a generic approach to preference management as suggested
here. Some of the related approaches listed in Marcel's GSoC document try to
provide structures for capturing this data explicitly.

But ultimately, what's missing is someone who captures and provides this
data for existing preferences. The preference registry suggested by Marcel
could be a good place to collect contributions to this end, both from the
respective projects themselves and/or from third party contributors.

Some meta-data worth mentioning:

i) Preference Dependencies

Changing some value foo=true in the Preferences UI will often change other
related values, too, e.g. bar=false. These dependencies need to be taken
into account when making subsets/groups of settings available. Making
inconsistent changes that would usually be prevented by the UI can lead to
some strange results, as I had to learn the first time I experimented with
Workspace Mechanic - up to breaking my workspace (although that should
probably be considered a bug...)

ii) Preference Sharing Strategy

Most preferences (bool/int/...) don't make problems. Others, like local
histories, are workspace- or user-specific. Applying them elsewhere might
even be harmful (e.g. when containing absolute pathes). This gets a bit more
interesting when it comes to complex preference values (e.g. serialized XML
documents). Knowing a strategy - or even some specific data handler, as
suggested in Marcel's proposal -  per preference key would be very helpful here.

iii) Presentation

Already suggested in the GSoC document. With human-readable preference names
only available in PreferencePage implementation code, a different source for
comprehensible names is needed for presenting preferences, e.g. when it
comes to creating groups, or for reviewing what I'm about to apply
to my workspace.

Collecting this meta-data might also help projects like the (now dormant?)
e4preferences in the future to solve their chicken-and-egg problem of
missing data and provide a way back for the assembled meta-data into
projects' code bases.


3. Privacy and Confidentiality

Although for the most part, preferences are far less problematic in this
regard than user activities or actual code bases, they are not free of
problematic areas. Especially given the rather strict German privacy and
data protection laws, this has already proven to be a challenge for us.

For example, the mere existence of certain preferences could be used to
deduce what kind of work a user does. Class or file names from "Recently
used" settings, or template copyright headers, might contain information
like internal project names, which some companies can be very paranoid
about. Changes to "Recently used"s and other preferences capturing local
state could maybe be used to get some sort of rudimentary activity profile.

Those examples seem a bit paranoid, but we've actually been confronted with
these kinds of concerns. So at the very least, a good preview of what I'm
about to share would probably be important. Beyond that, I'm not sure what
this would mean for the Foundation when it comes e.g. to access to
aggregated data. Maybe something similar to what we had with the usage data
analyzer?


*TL;DR* - we've already delved into this to some degree and consider
preference management a very important issue that can help make the Eclipse
IDE a lot more attractive to users. So we are looking forward to the results
of this meeting :)


Carsten


On 18.03.2014 00:28, Mike Milinkovich wrote:
> 
> Folks, please note that the room is actually 90*_2_*1, not 9031. Sorry 
> about that.  See you there.
> 
> On 12/03/2014 3:30 PM, Mike Milinkovich wrote:
>> On 12/03/2014 3:25 PM, Denis Roy wrote:
>>> I must apologize -- I misread the Doodle as Eastern time when I cast 
>>> my selections.  I have a talk on Tuesday at 2:15pm PT.
>>>
>>> I've updated my selections to reflect this.
>>
>> Given that Denis is in charge of anything LDAP-related at the Eclipse 
>> Foundation, I would really like to have him there. I went back at 
>> looked at the Doodle poll and the conference schedule, and my new 
>> proposal is
>>
>> 12:30-1:30PM Pacific Time
>> Wednesday, March 19th
>> Suite 9031
>>
>> This is in the lunch slot, and will hopefully give people enough time 
>> to grab a quick bite between 11:50 and 12:30 and then head to the 
>> suite for the meeting.
>>
>> Hopefully this is our last go-around on this!
> 
> 
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 

-- 
Yatta Solutions GmbH
- Carsten Reckord -

  t  +49 (0)561 5743277-33
  f  +49 (0)561 5743277-8833
  e  reckord@xxxxxxxx

Anschrift Office Kassel
  Ludwig-Erhard-Straße 12
  34131 Kassel

Anschrift Office Frankfurt a.M.
  Mainzer Landstraße 50
  60325 Frankfurt a.M.

Sitz, Handelsregister:
  Sitz der Gesellschaft: Kassel
  Amtsgericht Kassel, HRB 14720
  USt-IdNr DE263191529

Geschäftsführung:
  Johannes Jacop
  Dr. Christian Schneider

Kontakt Geschäftsstelle:
  t  +49 (0)561 5743277-0
  f  +49 (0)561 5743277-88
  e  info@xxxxxxxx