[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] Project Preference Store
- From: "James Blackburn" <jamesblackburn@xxxxxxxxx>
- Date: Tue, 21 Oct 2008 09:06:32 +0100
- Delivered-to: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qsKBRJJZJNOL6l1bFgBwqV9Vl0+51p4U/noCRhAdaAQ=; b=J08xFTKr8NTlu4+5qZ5YqNFslrN9sNs74MxC8P/8QLkkAnIp1kAKOj59dEBNOIr+1L pMnuN+8oT1lk7H8cJQVxPgMfkBhMtG61Rs9F018+Spa4Mtsi0UH3xRfRdC6+H5Ye5Tz1 QcEmgy/2Rihmz+p6QImztvDRb2aSSYADF7oqA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SAVWkhRzKQ+wzHFF5wwdyQl75UK0W124TpKIl2iyK2yGgtVvRwXF8wApzU9cMfHq0L 5XnMHKXowPDBABfZknxWY8CvKJ52oBPx+kvtlkAi4L4VMAiMy/2E9L1UW0hCEKDLkU3N 7BrJv4wx0q0jlckOt9jEJ8ENPYGvQq7HdJNa8=
On Tue, Oct 21, 2008 at 2:58 AM, Schaefer, Doug
> 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();
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
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.