X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HSh7j9fy0PqrzJXNeKxMYhDPd5Wj7ueVOW44cYttXiE=; b=kfzxCa6AQ66alzPm2ftlAbQoYt6D6lHZNnCNYHmp53JLnSFOc9mDmj5ucv8dAdQvc2 CZqzA+1fVe88pa+rLT9ferWK/u9fvhRd7CKLCmXaXcg9WbRUdtQ0oIJYgIrjEGHABoI/ C835uwTExPecrJE0BO7I5ObyFXl7DTjT/EuIdE5LS6fvcwNYBsPJkVl7Lqg1VCQp5cgi EHDiteWTFuDKbW/+nqgIsekZ4BngtY+zMFDPnHEf4VTeem6AMkSetqiRPZM5biwejzhy EI9Pkq1tLgUw+J5uS3hV6AHXrei+T719XnKTgP7jWe0lTVrswVCd8ptn70Z4k7l7iHQe lIsQ== MIME-Version: 1.0 X-Received: by 10.194.6.98 with SMTP id z2mr102765665wjz.101.1452037957556; Tue, 05 Jan 2016 15:52:37 -0800 (PST) In-Reply-To: <8E0210CD-0694-4717-A7B1-3224E39691DA@sbcglobal.net> References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com> <20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se> <8E0210CD-0694-4717-A7B1-3224E39691DA AT sbcglobal DOT net> Date: Tue, 5 Jan 2016 14:52:37 -0900 Message-ID: Subject: Re: [geda-user] A fileformat library From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=047d7b5d3e64a9239f05289eee41 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --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] 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


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@= aspodata.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 Joh= n on this.
> If you want to change the file format, you first have to provide some<= br> > goodies that will make people to accept it.

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

Ed

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.

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.

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>
Britton



=C2=A0

--047d7b5d3e64a9239f05289eee41--