Dear Gary,
1) Undo would indeed be a great help. That is why we have had it on our
todo list for so long. Unfortunately it would require a *major* change in
the entire API, with some tricky problems on top of that. Not for a long
time I am afraid, unless somebody can tell us what we should postpone to
make place for it.
2) DataShifter. It might be possible to let DataShifter be called from
inside Analysis (I am neither the one who knows nor the one who would have
to do it). We take note. But it would still work the same way. The problem
about 'importing native format data' is that the CCPN objects are all
linked together. Importing e.g. a peaklist means you must decide how to
handle all the links that go from the peaks to something else. That is
often complicated, and it reuires special purpose handwritten code for
every single case that you decide to support.
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, Gary Thompson wrote:
> 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
> -------------------------------------------------------------------
>
|