Hi all, FWIW:
1) I think that by means of either ASCII, XML or any other well defined format, about everything needed can be described (BTW I'm not advocating XML here). The question is rather "What needs to be described for the next step in the design flow". And are there any steps to be made back ? (as a result of gate swapping, or whatever the reason is). Do we need to back annotate for instance from pcb to gschem etc. ? How would that be encapsulated in a data centric model, and is this managable for very large projects, just because of the "loss in translation". By means of writing an auto-router for gschem to draw the altered nets in a neat way ? I took a look at IPC-2511 and IPC-2581, I even looked at Intermedius (http://www.intermedius.com/), they all have (propriety?) standards that seem complex. I would rather gaf stick to the KISS principle. For nowadays workstations it's no problem to "push harder" instead of "pushing smarter". 2) *nix has a reputation of being tool centric, and nobody complains !?, just write a couple of perl-, python- or shell scripts, and the problem could be solved. Is *nix growing toward a data centric OS ?. 3) IMHO gaf should concentrate on improving the tools and automated translators to other tools. I think that the above mentioned gschem2pcb is a good example, why not write pcb2gschem, pcb2vrml, pcb2dxf et al. If the tools are complete, without serious bugs and all foresee-able translators are written and automated, __and__ we have a user base (main stream ?) that is satisfied (no wishlist no more), then and only then let us consider data centric. 4) I recall an email, about a week ago, about a user complaining about almost anything that can go wrong for the average gaf-user. So let's keep that in mind, don't change the subject in order to avert the raised issues. Life is not going to be any better in a data centric universe if the tools ain't better. Just my EUR 0.01 Kind regards, Bert Timmerman. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Magnus Danielson Sent: zondag 9 januari 2005 22:46 To: [email protected]; [EMAIL PROTECTED] Subject: Re: gEDA: Tool Centric and Data Centric From: Al Davis <[EMAIL PROTECTED]> Subject: Re: gEDA: Tool Centric and Data Centric Date: Sun, 9 Jan 2005 15:21:47 -0500 Message-ID: <[EMAIL PROTECTED]> > On Friday 07 January 2005 02:36 pm, Steve Meier wrote: > > Tool Centric and Data Centric > > > > Tool Centric systems move data from one tool to the next in a > > sequential flow. This forces the user to be aware of back > > annotation in-order to complete the design and keep all > > documents current and correct. > > > > Data Centric systems share the data in common formats. As one > > task manipulates the shared data all other views (documents) > > are automatically updated. > > > > Currently, gEDA tends to be a tool centric collection. > > That's what I have been trying to say. We need a data centric > system for interchange between tools. I agree. Tools isn't what is interesting in the end of the day. It's their usage! > Ideally, the data centric format would be supported directly by > all of the tools. Practically, it can be done through > translators, so existing tools don't need to change. The > translators can be run automatically on loading or saving,so it > looks seemless to users. In theory yes, but there will probably be a certain amount of translation or else some usefull information will be "Lost in translation". Look at GENCAM to see a XML-based format which handles much, but not all, of what needs to be in there eventually. > Eventually, the data centric format will benefit the individual > tools too, by freeing them from the data structure mistakes of > the past. Indeed. But a good format also requires a certain amount of forward looking as well as design-considerations such that new features, types of objects, hell completely new concepts can be added. On the same time may the object types already defined be ammended, additional fields and attributes (not used in the strict gEDA sense) defined etc. Eventually should there also be a strategy on how a file in such a format can be transformed into a file in a new variant of the format, information-wise lossless, when objects can have changed throughout. The whole point about CAD/EDA is to aid the designer in managing the sheer amount of information and also to help redraw things after updating the informaiton. It is the designer(s) inability to handle the amount of information which brings them to use CAD/EDA tools, thus the tools must be designed with this in mind, this is where the true power of the tool (may) lie. I haven't looked on the details, but I think we might want to look at EDIF here. There is BTW another little quirkiness of gEDA, there is alot of exports out of gEDA, but how about imports? Cheers, Magnus
