Patrick van der Wel wrote:
> 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
This would work quite well but you do need to give the user the chance
to clear the lock file eg if a crash has happened. As an example
fiorefox can get ihn a real twist about locks and they really are really
well hidden under .mozilla in directories uned a further directory
called jhiofjspousdav or some such!
One answer would be to put the machine name and process id of the
process that startesd analysis in the lock file (yes I know this si
platform dependant but really there are only two os's to worry about
unix [linux, osx, solaris etc] and widnows. The you could check if the
lock process was still running and on this machine.
Two other request I would have are
1. is is possible to add undo to the datamodel? (yep i know this is a
hard one but it make a HUGE difference)
2. could the functionality of datashifter (??) be partially integrated
with analysis. It seems really strange that analysis has no methodology
for importing data of it own native type into itself and that you have
to save a project to disk and then transfer the data and reopen rather
than importing
regards
gary
>
> 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
>>>
>
> .
>
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: [log in to unmask] Fax +44-113-2331407
-------------------------------------------------------------------
|