[cad-linux-dev] Re: uber-converter
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- To: <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Mon, 7 Jun 2004 12:19:28 +1000
----- Original Message -----
From: "Eric Wilhelm" <ewilhelm@xxxxxxxxxxxxx>
To: <cad-linux-dev@xxxxxxxxxxxxx>
Sent: Monday, June 07, 2004 11:12 AM
Subject: [cad-linux-dev] Re: uber-converter
> # The following was supposedly scribed by
> # cr88192
> # on Sunday 06 June 2004 07:06 pm:
>
> > <x xmlns="http : //bar.org/xmlns/gs_cad-0.95">
> > <cog dir="0,0,0"/>
> > </x>
> ></polygon>
> >
> >ok, yes, this kind of thing would be pretty messy and bulky, but the
point
> >was to show ability to tack on new features...
>
> But we can also do that with YAML and without having a bunch of </>. The
> main problem that I see with xml is that so many tools are going to treat
> whitespace as optional, which doesn't mesh well with version control.
>
understood.
low level version control may be problematic (I had imagined higher-level
version control).
in the case of the database, assumably it is going to manage its own files
(thus not much of an issue here).
> If we want a hierarchical format, then maybe YAML is the way to go. New
> features could be added just as easily.
>
yes.
yaml may be more readable, I am unsure wrt other criteria...
> Also, in terms of networking. I think something which shares data by
cloning
> subversion servers may be more effective. If they all communicate to stay
in
> sync, then only the diffs would have to be sent to come up to the current
> version.
>
this is also very well possible with xmpp (if one can tolerate the xml).
I had recently done a 3d chat thinggy over xmpp, which demonstrates just how
harsh the karma limits can be (I can only send an update every few seconds
to stay within limits).
part of the coolness was that I used the existing chat functionality, so
basically only a small amount of custom protocol was done (sending out
updates and such).
others have done similar (a recent example was someone having a fairly cool
2d avatar based client that attached itself to webpages...).
> >assumably hand-editing models will be rare anyways...
>
> Hand-editing would be rare in use, but in development it would be nice to
open
> the file and make a quick change to a coordinate, or verify the sanity.
I'm
> not sure that the xml is going to be very readable (unless every
xml-writing
> library is going to so nicely indent as you have done above.)
>
agreed.
typically I use different printers for file and network stuff. my file
printing stuff typically uses a nicer (formatted) representation, and my
network stuff typically forgoes all formatting/optional whitespace.
I don't think this issue is that signifigant though. I can still read
through large chunks of unformatted xml to find problems in my network code
and such...
> Transparency is the primary goal of the textual format, and I don't think
XML
> really gives that.
>
I believe it is flexibility...
for me flexibility implies the ability to tack on new features as needed
without breaking anything...
I am thinking yaml might be a bit overly structured, and this might
interfere with the ability to easily tack things on...
I believe the core should be minimalistic and extensible, the rest should be
extensions...
ammusing:
I once somewhat disliked xml for many of the same reasons (size, ugliness,
..);
eventually I was won over by its excessive generalness from the same things
which made it ugly (only really having strings as a basic type);
at first I disliked the seperation of tags and attributes, later this
distinction showed itself as quite useful;
..
before my favored syntax had been s-expressions (I never really liked yaml
that much though...).
misc:
I was considering the idea of rendering directly from xml parse trees, but I
am unsure if this could offer sufficient performance...
most likely I will need to rewrite my current geometry system in any case,
it is just too inflexible at present...
maybe I could make more use of my type system, which could allow retaining a
lot of stuff, but wouldn't fix much (a minor gain in flexibility, a minor
cost in performance...).
eg:
a conceptual "type", some properties (dynamically typed), and a group of
dynamically typed members.
example (in a conceptual syntax):
polygon(vertices:=3, texture:="brown.tga")
{
vertex(origin:=#[-100,0,100], st:=#[0,1])
{
quote_xml
{
<x xmlns="http : //bar.org/xmlns/gs_cad-0.95">
<mass value="1.0"/>
</x>
}
}
...
}
this could work, and would also allow attaching any unknown xml to the model
(since the xml parse trees are covered by my typesystem...).
this will just be viewed as an implementation issue...
all for now.
Other related posts:
