Skip to main content

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

On Tue, Oct 21, 2008 at 2:19 PM, Elena Laskavaia <elaskavaia@xxxxxxx> wrote:
> I like an idea to use API for storage, this way we can perhaps substitute it
> with our own version and store stuff directly in makefiles for example?
> Or this does not go that far?

If you wanted to do that, that would indeed be possible.  My current
implementation hangs off of a new AbstractCProjectDescriptionStorage
which has abstract methods for :
- getting the project description (which returns a read-only /
writable / empty) project description as appropriate:
	public abstract ICProjectDescription getProjectDescription(int flags,
IProgressMonitor monitor);
- setting the project description (which atomically replaces the
current read-only default project description with the new one):
	/**
	 * Callback
	 *   - Actually set the current in memory ICProjectDescription to this
	 *   - If this requires modification of workspace resources then
don't serialize
	 * @param des
	 * @param overwriteIfExists
	 * @return boolean indicating whether existing read-only project
description should be replaced
	 */
	public abstract boolean setCurrentDescription(ICProjectDescription
des, boolean overwriteIfExists);
- create description serialization runnable which returns an
IWorkspaceRunnable for actually persisting the current project
description to disk (if that requires workspace modification of
resources).
	/**
	 * Callback
	 *   -  Return an IWorkspaceRunnable which will actually perform the
serialization of the
	 *      current project description or null if not required
	 * @return IWorkspaceRunnable that will perform the serialization
	 */
	public abstract IWorkspaceRunnable createDesSerializationRunnable()
throws CoreException;


Today it's possible to create a CProjectDescriptionEvent listener
which performs some action based on a project description delta.  But
it's not possible to influence how the description is stored and
loaded.

Cheers,

James


>
>
> James Blackburn wrote:
>>
>> 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.
>>
>> Cheers,
>>
>> James
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>


Back to the top