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
