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
>
|