Damien, thanks for your input...to cut to the chase: What are your sentiments regarding the encryption you mentioned? I must admit we haven't given this facet a lot of thought (partly because - as McNeel employees - we rarely have to deal with protection and secrecy).
To what extent do you feel we should provide mechanisms to encrypt/ protect/lock files? -- David Rutten Robert McNeel & Associates On Oct 1, 6:39 pm, damien_alomar <[EMAIL PROTECTED]> wrote: > 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
