[cad-linux-dev] Re: Tell me why this won't work, if you would be so kind.

  • From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
  • To: cad-linux-dev@xxxxxxxxxxxxx
  • Date: Thu, 13 Nov 2003 21:49:27 -0600

> The following was supposedly scribed by
> Jeffrey McGrew
> on Wednesday 12 November 2003 11:32 am:

>Thanks for this! It's right along the lines
>of what I was thinking; in that the same techniques
>used by *nix filesystems, and the 'way of unix',
>could be applied to the world of CAD.
>
>Simply wonderful!
>
>I've got more thinking/reading to do!

We've all got a lot of thinking to do.  I'm glad to hear that yet another user 
and potential programmer has been thinking along these lines.

Definitely feel free to throw down some thoughts on the wiki.  Doesn't look 
like it has been touched since I started listing out keywords late one night 
(please replace that boring list with something more descriptive.)

I've been really busy lately, but mostly programming on or related to the 
CAD::Drawing perl module (sorry this isn't in the wild yet.)

As I started adding a bit of a Tk gui to it the other day, I realized that it 
is not nearly so important how you store the data as it is how you access it.  

Textual data might be the key to throw the floodgates open, but iges and step 
have been around for a while.  

Atomic files and a directory hierarchy seem like a good direction, but this 
loosens the organizational structure (maybe just enough, but also maybe too 
much (probably at least more than you want to deal with in a bash script over 
the course of a large project.))

I've been messing with sql and storing data via postgresql, but the wordiness 
of sql statements and flatness of tables seems rather dissappointing as I get 
into it (not to mention the latency, etc.)

I think what would be more helpful (regardless of the format/storage/ipc 
methods) would be to have a geometry shell (this will require a better name 
than Bourne Again Geometry, but we'll get back to that.)  The idea is to 
provide a super-thin layer of abstraction so that instead of stripping 
linefeeds and splitting at whitespace, your tools present the file already 
turned into some geometry.  Re-invent the pipe to pass 2D or 3D coordinates 
or something and replace the pager with a gui viewer.  

Maybe it should have a GEOIN and GEOOUT hooked up as the default I/O handles 
so that 'print $pt' draws a point (and if you are running 'xtail -f drwdb' it 
shows up on the screen in the graphical "pager".)  If you need to drop down a 
level and see the numbers as text, you would look at STDOUT, but after 
programming "in the dark" for almost a year, I'm tired of looking at text and 
imagining.

--Eric

Other related posts: