Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Project Preference Store

Hi Doug,

On Tue, Oct 21, 2008 at 2:58 AM, Schaefer, Doug
<Doug.Schaefer@xxxxxxxxxxxxx> wrote:
> Hey gang, I was just looking through the Eclipse/OSGi preference system in
> search of an alternative to our proprietary and somewhat unprotected
> .cproject file. I know we did put some managed build settings in the Project
> preferences years ago. Any thoughts about whether it makes sense to put them
> all there? I'm not sure what it buys us, but I like some of the guarantees
> the Preference class makes on multi-threaded access (or does that just
> introduce more deadlocks, hmm).

There are a couple of issues I can forsee with this:
- How do you handle ICSettingsStorage ICStoargeElement trees ?
  Currently everything is stored in a tree. Key / Value preferences
aren't really a suitable replacement (and I think storing xml trees in
values will make version control even harder...)
- How do you handle the getProjectDescription(...); do_some_stuff();
setProjectDescription() workflow?

I've been working on (with holiday and interruptsion) a pluggable
storage layer for the back-end of core.model.  The one API change I've
made (so far -- though this could be fixed) is:
Element getProjectData(String id);  => ICStorageElement
getProjectStorageElement(String id)

As I see it, given that the writable XML trees are thread local, all
the current synchronization on
CProjectDescriptionManager.getInstance() is overzealous.

My idea is for CProjectDescriptionManager to delegate settings
load/store to a particular ProjectStorage.  All the configuration
classes now use enhanced versions of ICStorageElement rooted at
ICSettingStorage.  Synchronization occurs in the ProjectStorage
back-end -- and is therefore explicitly project scoped  (It therefore
leaves ProjectStorageProviders free to implement different storage
schemes with their own locking mechanisms).

I hope to have a patch on a bug with the existing XML model ported to
this new world before the end of the week.  I still believe you're
right about tidying up the build system, but I'm personally not
confident enough to just start again from scratch especailly given the
long legacy of API consumers are expecting to see.



Back to the top