[gmx-developers] libxml2 versus JSON

[David van der Spoel]

On 25/05/16 15:43, Erik Lindahl wrote:
> Hi,
>
>> On 25 May 2016, at 14:58, David van der Spoel <spoel at xray.bmc.uu.se> wrote:
>>>
>> Why?
>> Maybe I misunderstand you completely, but if we assume we fill a data structure, the intermediate routine (doing the JSON I/O) can do what it likes right? A structure like
>>
>> struct GmxTree
>> {
>>    std::string    name, value;
>>    struct GmxTree branch;
>>    struct GmxTree next;
>> };
>>
>> can be mapped to most anything, right?
>
> … and that’s pretty much exactly the problem with that approach :-) That would “solve” the problem by just exposing a lower-level data structure, there would be no standard whatsoever for how we do or document things, and before we know it each file would have its own set of standards.
>
> We need logically consistent ways or organizing (and naming) or data, and the API for our module should likely try to reflect this logic rather than rewriting a low-level API to JSON.
>
You are absolutely right that my "approach" does not give us more than 
independence from the underlying library. However my concern has been 
for a while that waiting for one monster file format does not get us 
further either. Fitting force field files, topologies and lots of random 
data all in one structure is not the way forward either.

But rather than whining I will propose a JSON schema for the WAXS patch 
that is in gerrit, then we can take the discussion from there.


> Cheers,
>
> Erik
>
>


-- 
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