Re: [Avogadro-devel] CJSON format proposal

2016-11-22 Thread Boone, Paul
On November 21, 2016 at 11:25:40 AM, Marcus D. Hanwell (marcus.hanw...@kitware.com) wrote: Something like (made up and not validated): { "molecule": "myMolecule", "inchi": "correctInChI_here", "name": "friendlyName", "atoms": [ { "atomicNumber': 4, "atomicSymbol

Re: [Avogadro-devel] CJSON format proposal

2016-11-21 Thread Patrick Fuller
Hi Marcus, I completely agree. I think "overly verbose but flexible" is the definition of JSON, and its verbosity can be frustrating at times. It's also messy in statically typed languages - particularly typecasting as you unravel highly nested structures. Supporting a maximally readable JSON wou

Re: [Avogadro-devel] CJSON format proposal

2016-11-21 Thread Marcus D. Hanwell
On Mon, Nov 21, 2016 at 10:47 AM, Patrick Fuller wrote: > For what it's worth, I thought I'd try to add my outside opinion to the > discussion. > > Where I'm coming from - I don't think that performance has ever been the > motivation behind the JSON format. I view JSON as developer friendly and >

Re: [Avogadro-devel] CJSON format proposal

2016-11-21 Thread Patrick Fuller
For what it's worth, I thought I'd try to add my outside opinion to the discussion. Where I'm coming from - I don't think that performance has ever been the motivation behind the JSON format. I view JSON as developer friendly and easy to implement, but also as the first thing to abandon if perform

Re: [Avogadro-devel] CJSON format proposal

2016-11-20 Thread Marcus D. Hanwell
On Sun, Nov 20, 2016 at 11:57 AM, Boone, Paul wrote: > Can you explain more how BSON fits in here? If CJSON were supposed to be a > file format for internal interchange, then I have nothing against storing > coords as one array and then processing them when you read it in or out. BSON is used by

Re: [Avogadro-devel] CJSON format proposal

2016-11-20 Thread Geoffrey Hutchison
> I specifically wouldn’t worry about space considerations of the sub-arrays, > but I don’t ever worry about space for JSON since it just wasn’t intended for > that. Right now I think the biggest CJSON file we’re testing with for the > python interface is about 117k, which I don’t think of as la

Re: [Avogadro-devel] CJSON format proposal

2016-11-20 Thread Boone, Paul
Can you explain more how BSON fits in here? If CJSON were supposed to be a file format for internal interchange, then I have nothing against storing coords as one array and then processing them when you read it in or out. For the python interface though, we were going to use CJSON as a public i

Re: [Avogadro-devel] CJSON format proposal

2016-11-18 Thread Marcus D. Hanwell
On Fri, Nov 18, 2016 at 11:11 AM, Boone, Paul wrote: > > I’m working with Geoff on the python plugin architecture. There are a couple > small change to the cjson format I’d like to propose. Currently, the cjson > has structure that is implied but not explicit in the file itself, and this > forces