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
