Mail Archives: geda-user/2016/01/05/18:52:50
--047d7b5d3e64a9239f05289eee41
Content-Type: text/plain; charset=UTF-8
On Tue, Jan 5, 2016 at 9:45 AM, Edward Hennessy (ehennes AT sbcglobal DOT net)
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
> > On Jan 5, 2016, at 10:21 AM, karl AT aspodata DOT se wrote:
> >
> > Also, there is no reason to change a file format unless you change the
> > functionality it provides, I have to "side heavily" with John on this.
> > If you want to change the file format, you first have to provide some
> > goodies that will make people to accept it.
>
> Agreed. Additionally, many users have a large investments of time and
> energy into developing their CAD libraries. Any changes to the file format
> should strive to maintain compatibility with user's existing CAD libraries.
> Ed
>
I recently did a tiny bit of work on the parser in pcb. Of course we
should continue to support it, but it's going to be tough to extend it
much. It's already overloaded in weird ways (e.g. thermals are parsed as
flags, with their own non-flex sub-syntax, even though they don't set any
actual flags). If you do extend it you do hard work and still only pcb can
read it. Of course you still have to teach the innards of pcb about your
extensions in order for them to do anything useful.
A new one-to-one equivalent format is actually less ambitious in itself
than extensions to the existing format. You get parsers in other languages
almost for free, and that's the major point. There is zero problem with
supporting the existing format as well.
The big potential down-side to *extending* via (not just supporting)
YAML/JSON/SQL, relative to extending the existing format is that tools
that do partial parse have no chance to continue working unmodified. This
sounds worse than it is though. Keep in mind that *any* change (including
extensions) to the existing format *may* break existing partial parsers.
There's no way to know how they orient themselves. Speaking for myself, I
prefer softwares to spit out a big fat FAIL message and quit, than to
silently try to work when they cannot guarantee correct operation.
Britton
--047d7b5d3e64a9239f05289eee41
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jan 5, 2016 at 9:45 AM, Edward Hennessy (<a href=3D"mailto:ehen=
nes AT sbcglobal DOT net">ehennes AT sbcglobal DOT net</a>) [via <a href=3D"mailto:geda-u=
ser AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=
=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br=
>
> On Jan 5, 2016, at 10:21 AM, <a href=3D"mailto:karl AT aspodata DOT se">karl@=
aspodata.se</a> wrote:<br>
><br>
> Also, there is no reason to change a file format unless you change the=
<br>
> functionality it provides, I have to "side heavily" with Joh=
n on this.<br>
> If you want to change the file format, you first have to provide some<=
br>
> goodies that will make people to accept it.<br>
<br>
</span>Agreed. Additionally, many users have a large investments of time an=
d energy into developing their CAD libraries. Any changes to the file forma=
t should strive to maintain compatibility with user's existing CAD libr=
aries.=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ed<br></blockquote><div><br></div><div style=3D"">I recently did a tiny bit=
of work on the parser in pcb.=C2=A0 Of course we should continue to suppor=
t it, but it's going to be tough to extend it much.=C2=A0 It's alre=
ady overloaded in weird ways (e.g. thermals are parsed as flags, with their=
own non-flex sub-syntax, even though they don't set any actual flags).=
=C2=A0 If you do extend it you do hard work and still only pcb can read it.=
=C2=A0 Of course you still have to teach the innards of pcb about your exte=
nsions in order for them to do anything useful.</div><div style=3D""><br></=
div><div style=3D"">A new one-to-one equivalent format is actually less amb=
itious in itself than extensions to the existing format.=C2=A0 You get pars=
ers in other languages almost for free, and that's the major point.=C2=
=A0 There is zero problem with supporting the existing format as well.</div=
><div style=3D""><br></div><div style=3D"">The big potential down-side to *=
extending* via (not just supporting) =C2=A0YAML/JSON/SQL, relative to exten=
ding the existing format is that tools that do partial parse have no chance=
to continue working unmodified.=C2=A0 This sounds worse than it is though.=
=C2=A0 Keep in mind that *any* change (including extensions) to the existin=
g format *may* break existing partial parsers.=C2=A0 There's no way to =
know how they orient themselves.=C2=A0 Speaking for myself, I prefer softwa=
res to spit out a big fat FAIL message and quit, than to silently try to wo=
rk when they cannot guarantee correct operation.</div><div style=3D""><br><=
/div><div style=3D"">Britton</div><div style=3D""><br></div><div style=3D""=
><br></div><div style=3D""><br></div><div>=C2=A0</div></div><br></div></div=
>
--047d7b5d3e64a9239f05289eee41--
- Raw text -