David, Although I think a human readable format would be good, I think that an OpenNURBS approach would be a great way to go and would offer a number of advantages to making the format readable. The big thing, for me at least, is looking at the potentials for this (GH in general) to grow. Obviously you (McNeel I mean) aren't necessarily interested in moving GH to another platform, and rightfully so. I could see either a 3rd party or a private company wanting to write a "wrm translator" that would "reassemble" a given worm definition within another platform and that would definitely be something that could be progressed or encouraged by having some sort of I/O SDK. For some reason, I feel that an XML description would lead to a more "manual" way of having to go through the file. Also, I feel that some of the complexity that can potentially be in a wrm definition (clusters, expressions within components, order of inheritance for multiple data streams, connections between components) would yield a very cumbersome process of understanding the information within the file. In the end, I don't think that even a human readable format is going to be that readable anyway (XML still looks like chinese to most people). It may help some super advanced users (and you of course), but data robustness is more important IMHO. I think that looking towards future features like custom components and an encryption system it would be easier to support those with an sdk as opposed to an xml format. The only real advantages to XML from my point of view is having it in "plain english", and having it be more adaptable. There are more downsides with an SDK (development time, support), but more upsides as well (more robustness)....XML is pretty even keel I guess.
Ultimately, I think that XML is more of a short term solution and an I/ O SDK would be more long term. I personally think that putting together an I/O SDK would be worth the development time that it would take to do it. As far as a support basis, the I/O SDK doesn't necessarily have to be public immediately. So support would be on a request basis. Thats my opinion for now, coming from a semi-Programmer/power users that has no file reading experience :) Just keep the good stuff rolling, David. Best Regards, Damien On Oct 1, 9:47 am, David Rutten <[EMAIL PROTECTED]> wrote: > Hi Anton, > > all good points. It is at the moment difficult to embed custom data in > Rhino files if you cannot attach it to objects. Once this is a bit > easier, it will be possible for Grasshopper to serialize all data into > the 3dm file, and you'll no longer have to bother with separate files > (though I do plan on keeping those around). This is not in any way > related to the actual definition of the grasshopper file though, in > the end, all we need to do is pour a bucket of bytes into Rhino and > get them out in the same order. > > I'm very fond of the idea of having a human readable format (not in > the least because it makes debugging future IO errors much easier), > but -as you pointed out- there is the matter of security and privacy. > Several people have asked for password protection on clusters etc. in > the past and it's a lot easier to encode binary goo than text based > xml. > > I'm undecided on the 'open-source' topic. It's a bit more work and > probably a lot more support in the long run, but I can see there are > some obvious benefits. I'll let this poll fester until after the > weekend before making up my mind. > > Thanks for your input, as usual. > > -- > David Rutten > Robert McNeel & Associates > > On Oct 1, 4:31 pm, quantx <[EMAIL PROTECTED]> wrote: > > > hi david, > > > just putting some thoughts out in the open. > > > i think both the xml and the opensource option would work fine for > > many of the people. a possible third one with let's say a closed > > "commercial" format depends on the future plans for grasshopper. Also > > the whole issue, maybe not so closely, but at least to some extent is > > related to what's planned for rhino 5 and the future of 3dm file > > format. one direction might be to aim for some hybridization between > > the two giving possibities to more tightly merge the parametric > > geometry with the rhino geometry and its implicit history. like in ICE > > or GC i suppose. > > > Other line of consideration that runs trough my mind impromptu is how > > one can reflect the current trend in advanced computer geometry where > > the principle Do-It-Yourself is more and more leading. Here i think a > > choice of XML (ascii/binary) would be more consistent with all the > > ease of use and transparency one gets nowadays, even when tapping deep > > into the resources - like mysql, rhinoscript, visual studio's express > > editions, processing. etc. All of these are meant for the non- > > developer guy/girl with little to none programming experience. > > > So with the xml standart it will be much easier for those characters > > to tap into the resources of direct file manipulation. depending also > > on a sdk or something. and for the more experienced users there would > > be already a huge know-how (techniques, tricks and so on ) around on > > the net about working with xml which maybe will allow for creative > > ideas to emerge on grasshopper file-format "hacks" that can also from > > time to time refresh you guys (the developers). similar to what is > > happening with google earth and the kml/kmz format. > > > Another issue that might be of interest is the possibility for the new > > definition format to work like a rhino "executable model". i.e. not to > > require opening the grasshopper editor but directly opeing the > > definition and through a series of dialog box prompts to present the > > parametric model to the user with an interface to play with it. this > > can be good for packaging and distributing gh defs to non-gh users. > > but maybe a more closed format would work out better in this case for > > security issues and so on. > > > Ok, enough blabbering :) > > greetings, > > anton > > > On Oct 1, 2:09 pm, David Rutten <[EMAIL PROTECTED]> wrote: > > > > Dear testers, > > > > it has become clear that the definition for Grasshopper files (*.wrm) > > > is causing more and more problems as the versions progress. Although > > > technically it is flawless, infinitely flexible and very efficient, > > > it's just too darn easy for humans to make mistakes while writing > > > reading/writing code. > > > > This probably means we'll have to redesign the format from the ground > > > up (while maintaining reading capacity for old files of course) and we > > > have a number of options open to us. Some of you have expressed > > > opinions about this in the past so I thought it prudent to ask before > > > retreating to my coding-cave. > > > > What we can do: > > > > 1) Make the format human readable. I.e. store it as plain text or XML. > > > Or at least have a flavour that is human readable, we could support > > > both binary and XML files with the same code. > > > > 2) Make the format open source. I.e. the logic that reads and writes > > > Grasshopper files could be a separate project which can be referenced > > > by other applications. Or, if not open source, at least share the dll > > > that would be required to read/write grasshopper files. > > > > 3) .... > > > > any thoughts/suggestions/brain-dumps/complaints/well-wishes are > > > welcome > > > > -- > > > David Rutten > > > Robert McNeel & Associates
