Getting the current active project

[Andreas Pakulat]

On 03.04.07 13:24:00, Andras Mantia wrote:
> On Tuesday 03 April 2007, Andreas Pakulat wrote:
> > Hmm, right. But this means that IProject has to parse the
> > locally-cached project file everytime its asked for a
> > KSharedConfig::Ptr (i.e. at least a reparseConfiguration() is
> > needed).
> 
> I don't know the current implementation, but I'd imagine the following:
> - if the file is local, open that file directly with KConfig
> - if the file is remote, download, open the downloaded file with KConfig

Correct until here.

> Everything is done the same way from this point on, except that there 
> are writes/actions  that trigger an upload, in which case 
> an "uploadProject" method is called which uploads if it was a remote 
> file (or let's say sync-s in case of local ones).

Uhm, well the problem here is that uploading cannot be done by IProject,
because it doesn't get notified when the Apply or Ok button in the
configuration dialog is hit. However the KConfigSkeleton for the current
dialog page will get notified and the upload would be in there (it would
also update the local cached files too). So the IProject needs to sync
with the locally cached files, everytime its projectConfiguration()
method is accessed.

Also I'm currently thinking about removing the local/globalFile
functions from IProject because those cannot be used reliably to read or
write the files.

> > > Of course a crash recovery mechanism is needed, so you don't loose
> > > your project changes if KDevelop crashed and the temporary project
> > > file was not uploaded yet.
> >
> > That is rather hard. If KDevelop crashes we can't do anything anymore
> > (without hooking into various unix signals, I think), especially not
> > upload a locally cached file.
> 
> I don't see the need of unix signals. Quanta has a crash-recovery 
> mechanism since quite some time for documents, and a similar could be 
> used for projects as well. The idea (in a simple form) is something 
> like the following:
> - keep the downloaded file in a separate temp directory
> - keep a list of what project was opened in kdeveloprc (or some other 
> config file)
> - when the project is closed, remove the entry from kdeveloprc
> 
> If KDevelop crashes, the entry from the kdeveloprc will not be removed, 
> so on the next startup it knows that there is a downloaded project 
> file, which can be used to recover and go on from the last state 
> instead of downloading an older version from the remote place.

This won't work in all cases. For example if kdevelop crashes and the
user uses other means to change the remote project file, we shouldn't be
uploading our local cache.

Also with the approach I have in mind there's only a very small timespan
during which a crash would loose the project configuration. Basically
because we upload it on each apply/ok click. Of course it can still
happen, but I really don't see a way to recover from a crash when we
don't know wether out locally cached file is still valid.

Andreas

-- 
You are confused; but this is your normal state.