Brian Smith wrote:
> On Tue, 18 Sep 2007, Rasmus Fogh wrote:
>
>> 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.
>
> Given the interconnectedness of the data model I don't really see how
> this can ever be achieved. Basically you're asking for a complete
> copy of the datamodel to be saved between each user operation which
> sould have major performance issues, innit?
no you don't have to save the complete model, you can save deltas and
use 'transactions' to note whats changed and then role back a set of
changes noteasy but with support from the datamodel quite feasable
nb as an aside I knew that this an absolutely outrageous request when I
posted it ;-) (but its also an important one....)
> Surely the way to go is to make sure that the programs all have a
> regular & frequent (15 min?) backup enabled _by default_ and that the
> backups rotate for a user specified (but say default 4) number of
> copies in a non-trampling and easily retrievable (and documented)
> way. Hopefully the paths stuff you're doing for 1.1 will make all
> this easier/more transparent.
>
>> 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.
>
> DataShifter & formatConverter are important for the whole CCPN effort
> (which is not just analysis) and is an area that certainly deserve
> some more attention. As well as the means by which existing users go
> to transfer data between projects, they are the route in for new users
> - we need them to be slick & documented to the point where users do
> not feel really comfortable using them. NB this needs detailed and
> constructive feedback from the users reading this on what
> functionality is broken/missing and to help with documentation for
> specific cases.
I agree with this data transfer is a very important are and it is one of
the first things many users will see when they start analysis...
My current pet peave is Link reosnances (apologies to wim!), in some
cases I have to run it over an over again because my resonances don't
have ranges that overlap (have you ever tried importing a restraint list
with only long range restraints its quite fun!) Also the other thing
with link resonances is that often i _know_ the information that it is
trying very hard to deduce (ie most external program only deal with
single chain and if I could tell analysis what chain that is it would
make the import process much smoother)
regards
gary
>
> Brian
>
--
-------------------------------------------------------------------
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
-------------------------------------------------------------------
|