Subject:
|
Re: Backwards Compatibility (Was Calling all Meta-commands)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sat, 15 Mar 2003 13:02:20 GMT
|
Viewed:
|
1640 times
|
| |
|
|
In lugnet.cad.dev, Orion Pobursky writes:
> In lugnet.cad.dev, Tim Courtney writes:
> > I think you could ask almost anyone here and they would say
> > backwards-compatibility is a must. That isn't a bad thing, so long as we
> > build a framework for legitimate advancement of the format in the future.
>
> I agree the backward compatibility is good, to a point. This is especially
> true for the parts library. Too many times we refuse to fix something or
> extend the file spec (e.g. new colors not able to be represented by existing
> color numbers) simply because we worry about backward compatibility. I've
> said this before and I'll say it again:
>
> It's time to abandon the old DOS LEdit and LDraw as our standard.
>
> What are we going to do when DOS support in PC OS's goes away completely?
> We need to move on to bigger and better ideas. Sure revamping the spec may
> make it more complicated but this will lead to a more functional and
> powerful system of tools.
>
> Please take these statements for what thet are worth, food for thought and
> not blind dogma.
Hi Orion,
Here is my take on the current state of LDraw related tools and parts
library. There are a few documents that sketch out the basic mechanics of
what we use today, but the real standards are the programs that we have that
use them. We have LDraw and LEdit, then MLCad, then L3P and on down the
line. We can't abandon these programs as our standard unless we document
what we've got today.
This web page http://www.ldraw.org/reference/specs/fileformat describes
the basic format of an LDraw file, and at the most basic level it does quite
well except for meta-commands. Short of introducing new record types,
meta-commands are the only extensible part of that definition. There are
many details from outside this document that need to be backfilled in here.
Non-planar quads is a no-no in part definitions, but nothing is said about
that in fileformat.
As Travis points out, it is unfortunate that comments and meta-commands
use the same record type, but the up side is that we've been able to extend
LDraw tools beyond James' original definition. My concerns here are for
namespace pollution, which is why I wanted to understand what the namespace
is today.
While the fileformat web page is accurate at one level, there are many
standards that must be followed when laying out parts in the parts library.
If these are documented, I don't know where, except in discussion here on
lugnet, and in L3P, the parts checker program. This issue is significant,
as the parts library is the most valuable part of the LDraw family (IMHO).
My hat is off to those unsung heroes creating the parts library, and
especially to Steve Bliss who works so hard as the leader and an individual
contributor. The recent efforts to upgrade the BFC document are great.
This documentation needs to be part of an overall LDraw specification,
rather than a seperate document that we have today.
BFC is just an example of the powerfull things we LDrawer's have added
using meta-commands. I'd like to officially document all the meta-commands
we can. I'm glad you are volunterring to help. I'm quite new to this whole
LDraw game, and you've got a much bigger knowledge base than I, so your
assistance in gathering up the user-defined meta-commands will be greatly
appreciated (not to mention your future contributions to the standards
body.) I also officially volunteer to be on the standards body.
I'm of the belief that changes need to be made that will end up being
incompatible with LDraw and LEdit, but will be evolutionary not
revolutionary. Allowing for RGB colors in part, line, triangle and quad
commands is a simple example. Once documented, it will be a simple change
to most LDraw CAD programs. Unfortunatly we lack source for LDraw and
LEdit, so they won't be able to be changed, so they will no longer be able
to be the file format checker programs. Maybe we can replace them with a
new program that is a compliance checker.
It will be easier to write the compliance checker program when we've got
the status quo documented, which is what I tried to start with when I made a
call for meta-commands.
Once we make it this far, we can look at future changes to the standard in
an organized fashion.
LSynth was the first time I actually needed data in the LDraw file format
that was not detailed using parts, lines, triangles and quads. I went to
look for documentation on how I might do this, and I was told to make sure
whatever I did was tollerable by the LDraw program. I was extremely
surprised by this answer. I've never run LDraw. Since that point, I've
been interested in an LDraw specification process, so that folks that want
to join in writing new LDraw compatible applications know where to start.
I'm quite glad to see the energy my call has unleashed.
Kevin
>
> ....
>
> Time for me to get off the soapbox before I cause more trouble.
>
> -Orion
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Backwards Compatibility (Was Calling all Meta-commands)
|
| (...) I agree the backward compatibility is good, to a point. This is especially true for the parts library. Too many times we refuse to fix something or extend the file spec (e.g. new colors not able to be represented by existing color numbers) (...) (22 years ago, 15-Mar-03, to lugnet.cad.dev)
|
154 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
