[gmx-developers] libxml2 versus JSON

[Mark Abraham]

Hi,

What's the scope? If we want to write a wrapper layer around some JSON code
so people can use it for parsing input files, while we have a way to
replace the dependency with something else in the future, then that's
pretty much fine by me.

What I'm not keen on is the rabbit hole of converting all our existing
parameter-like file formats to some JSON format. That amounts to re-writing
lots of our setup tools. That would likely be a big improvement in code
quality, but it's dozens of hours of input from quite a few people to agree
on how it should look, and then a few coding months to write tests,
re-implement the code, and get it reviewed. This create a bunch of friction
for users, for no immediate gain. Who's got the resources for that, and
what's the big payoff?

Mark

On Thu, May 12, 2016 at 5:25 PM David van der Spoel <spoel at xray.bmc.uu.se>
wrote:

> On 12/05/16 14:16, Erik Lindahl wrote:
> > Hi,
> >
> > While I’m all for JSON, the format per se isn’t critical. What is needed
> is for somebody (or a couple of people) to sit down and start working on a
> larger framework for writing and reading all sorts of data, and how to
> handle this in an abstract way. Then the actual file format is simply a
> module that can be replaced if we ever want to change it.  But, this will
> require volunteers!
> >
> This is what we discussed in the gerrit patch, to have a module on top
> of it that would form the API for the rest of the code. For me this is
> the most important thing to decide in gmx development in the near future.
>
> > Just picking a format and then having dozens of modules all fire away
> with creating their own data fields directly in that format doesn’t bring
> any more portability than using raw text files, IMHO :-)
> >
> > Cheers,
> >
> > Erik
> >
> >
> >
> >
> >> On 12 May 2016, at 12:40, David van der Spoel <spoel at xray.bmc.uu.se>
> wrote:
> >>
> >> Hi,
> >>
> >> with the developer meeting coming up next week I would like to once
> again bring up the issue of what file format to use for database files. We
> have discussed this for over ten years and not having a decision is
> stopping innovation.
> >>
> >> I propose we vote on it at the meeting next week if we can not reach
> concensus. Personally I am beyond caring which of the two as long as we
> make a decision - now we have nothing.
> >>
> >> Cheers,
> >> --
> >> David van der Spoel, Ph.D., Professor of Biology
> >> Dept. of Cell & Molec. Biol., Uppsala University.
> >> Box 596, 75124 Uppsala, Sweden. Phone:       +46184714205.
> >> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
> >> --
> >> Gromacs Developers mailing list
> >>
> >> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
> >>
> >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >>
> >> * For (un)subscribe requests visit
> >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
> >
>
>
> --
> David van der Spoel, Ph.D., Professor of Biology
> Dept. of Cell & Molec. Biol., Uppsala University.
> Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.
> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160512/dfc6d7c2/attachment-0002.html>