Re: [proteowizard-developer] MGF Conversion Support for Skyline

[Brendan M. <bre...@pr...>]

I would really prefer to have the full source file name that the MGF came
from.  In most existing cases, I will be able to show that to the user in
Skyline.  I actually still think we should just move to comma separated
fields in TITLE, and let people adapt.  Once they do adapt, we will be able
to add more comma separated fields in the future, if need be.  Just add a
flag for MSConvert and a checkbox for MSConvertGUI that allows people to
get the legacy behavior, which should not remain the default forever,
simply because it was the first thing we ever came up with.  Ideally the
number of people relying on this now is still small compared to what it can
become.  Let's move toward a more flexible format (comma separated <name>:
<value> pairs) now.

People managing pipelines generally will be a lot less affected by needing
to add a new flag or fix their code to handle comma separated properties
that naive users looking for out of the box solutions.

On Wed, May 30, 2012 at 11:40 AM, Matthew Chambers <
mat...@gm...> wrote:

> Compatibility is more important in the command-line version which is
> infinitely more likely to be
> included in an automated pipeline. So that's why the change can't go in
> Serializer_MGF. The checkbox
> for "TPP compatibility" is still sounding like the best option, defaulting
> to on.
>
> Brendan, you said you were going to adjust your parser to work with the
> old basename.1.1.2 format;
> does that mean I can keep to that format with "TPP compatibility" mode?
>
> -Matt
>
>
> On 5/30/2012 1:34 PM, Brendan MacLean wrote:
> > For TPP, doesn't the TPP release its own compatible msconvert?  I assume
> it does not rely on users
> > to maintain compatibility, which means this change will not impact TPP
> users, if it is trivial to
> > fix Mascot2XML at the same time that the new msconvert is adopted.
> >
> > Again, I would like to change the default to include more information
> that I require.  I am fine
> > with adding a switch at the same to make it possible to get legacy
> behavior.  But, we really cannot
> > keep default behavior frozen in time because it was our original choice
> and, therefore, change might
> > break someone.  All software would seize up with that approach.
> >
> > I certainly take backward compatibility seriously, but we also need to
> be able to move forward.
> >
> > On Wed, May 30, 2012 at 11:16 AM, Jimmy Eng <jk...@gm... <mailto:
> jk...@gm...>> wrote:
> >
> >     Brian, I'm just being a devils advocate here ...
> >
> >     The "others will adapt" statement might be amended to "others will
> >     adapt or not bother adapting as there are other ways to generate mgf
> >     files and the percentage of users this affects is tiny".   What about
> >     a pipeline developer's response like "Well, msconvert generated mgf
> >     files used to work with our pipeline.   Here's the required TITLE
> >     string that's the issue.  Not sure why they broke it, maybe you can
> >     ping the pwiz guys to give you an option to compliant mgf files like
> >     msconvert used to do.  Otherwise, here's a tool or workaround that
> you
> >     can use to generate compliant mgf files until that msconvert fix
> >     happens."
> >
> >     Again, it will be a trivial update to Mascot2XML to support the
> >     change.  I'm just thinking the notion that others will automatically
> >     adapt could be viewed as a bit presumptuous.
> >
> >     On Wed, May 30, 2012 at 10:55 AM, Brian Pratt <
> bri...@in...
> >     <mailto:bri...@in...>> wrote:
> >      > output file.  A robust parser will use or ignore it, others will
> adapt
> >      > and it probably won't be the first or last time for them.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> proteowizard-developer mailing list
> pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>