I have recently been worrying about the chances of concurrent access of
the same project by different users (on lab-computers that are easily
accessible for multiple people on the same project - a common scenario I
imagine).
I had thought that a relatively simple, although definitely not
fool-proof solution would be to at least associate lock files with the
project XML file. Surely this is not optimal (e.g. what happens when
Analysis crashes due to a failed network connection or something?), but
it would help a lot.
I am at this stage not *that* worried about having different projects
access (and change?) reference and other shared data. For the latter I
would assume that things are usually either copied, or separately
imported into each project and thus are not truly 'shared' (for most
Analysis users).
Patrick
Rasmus Fogh wrote:
> Dear Brian,
>
> Locking the files would not be that easy to set up. In version 1.1 we can
> have several Project.xml all pointing to the same set of data. This would
> make sense if e.g. you were working on different constraint lists and
> wanted the 'currentConstraintStore' to point to different files. Different
> projects will always share their reference data (ChemComps,
> NmrExpPrototypes, ChemElements, ...). You can also have different projects
> share 'real' data, for instance if you are using the same structures for
> different projects (of different complexes for instance). Obviously you
> would want to set the shared files to non-modifiable. But you can also
> have different projects point to the same modifiable data by mistake.
>
> Some things will get easier in version 1.1. In the standard set-up all
> modifiable data as well as the Project.xml will live under the same
> directory, so it will be easy to track what belongs together and (for the
> programs) to make sure it is pointing to the right files.
>
> Proper handling of concurrent access requires a database. Anything we
> could do in a file implementation would have to be simple and limited,
> otherwise we would end inventing our own DB system.
>
> I would like a more precise list of the kind of situation people want us
> to deal with. After all, users of e.g. Ansig accept that you cannot open
> the same file in two different places at the same time without corrupting
> your data. We could not guarantee against all possible contingencies - you
> may have heard that it is impossible to make anything foolproof, because
> the fools are too ingenious. But we could maybe deal with a limited number
> of common simple scenarios, if people could give us a list.
>
> Yours,
>
> Rasmus
>
> ---------------------------------------------------------------------------
> Dr. Rasmus H. Fogh Email: [log in to unmask]
> Dept. of Biochemistry, University of Cambridge,
> 80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
>
> On Tue, 18 Sep 2007, Brian Smith wrote:
>
>> On Tue, 18 Sep 2007, Wayne Boucher wrote:
>>
>>> On point (1), the three main menu items you can select are "new project",
>>> "open project" and "open spectra". The latter was meant as a way of
>>> looking at spectra without having to actually explicitly create a project
>>> (one is created for you automatically behind your back). I'm not sure how
>>> many people actually use that option so I wonder if we can always insist
>>> that people create a project. And I'm also not sure what the split
>>> between "new project" / "open project" is. We could perhaps have a dialog
>>> pop up where it gives you the option of doing one or the other (or also
>>> "open spectra" if we keep that). I guess that might help novices,
>>> although with so few menu choices not greyed out I would have hoped it
>>> wouldn't be that hard to have figured these out without additional
>>> prompting. What do people think?
>> I was happy with the way things are but agree that a dialog that offered a
>> choice between "new project"/"open project"/"open spectra" would be a
>> new-user friendly feature. However, what about when you just want to run
>> the analysis GUI to e.g. do an update? If this gets in and user profiles
>> come along, please could we have the option to have it not appear?
>>
>> Some kind of lock to prevent multiple instances trampling the same
>> storage along the lines Andy suggests would be a really good idea.
>>
>> Brian
>>
>> --
>> Dr. Brian O. Smith ---------------------- B Smith at bio gla ac uk
>> Division of Biochemistry & Molecular Biology,
>> Institute Biomedical & Life Sciences,
>> Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
>> Tel: 0141 330 5167/6459/3089 Fax: 0141 330 8640
>>
|