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=m0n5t3r.info; s=m0n5t3r; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=DXAwsUpZyKSvB3XQ62mwzLCtCzVtsqJZUuCWfU1FFyo=; b=eULEGbvlKb0o92Rwq4A0K2paZqiz05c0sPpBET4zx7SHHrENmBfkGhe3K+mQ0wg7HT o/pwJUR3k/JYWMHgl3I/fk92V4Flsgw32KgkvjZFbxpgWznV07uZcKJqvw/LhVBSBnPZ cP0xrid8YzuyfHa9JdIFoDRDGgblD8njqd+3k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=DXAwsUpZyKSvB3XQ62mwzLCtCzVtsqJZUuCWfU1FFyo=; b=CYO8sBdYkuF1mEnA5Dps6gpduplx3QnW7R3NZp0WcSPpws00BHnTe0O+fxJzNm2Fjg mhJ+CZgi0Z5yDQ+IIm/ck078kxTJsF0GrWnI7edxtr8Qmxu4O5D73c6kBlaX5R+2qgvF Mk9rcVwBH/T4ffaDKxT3rjBQm8MaofxLZnEix9F867rP1SGp7qcTjDnD+SzKhvbTQovk 0HGlIUciCD65bTLOOIWFkYz0tE6KDz9RRHBnEX4irDf4sCW+GPTrOMw0ruY/+oahCaaq JgpC3x3UjHgVzYLR6ecso+4cJ2CKHBh7bAWM55XUDIwoRxG76wR1s88TiEc1vNKVbarG rKQA== X-Gm-Message-State: ALoCoQmz+l/drtEuUwWHcV0p3Bq0YTQtpiSVrJ7atzDfuIUkbgt7nXqnRGVEns082Y7xmG15fBG/b8tWPoEIIkyxObi5Et8r9A== X-Received: by 10.194.116.40 with SMTP id jt8mr125579266wjb.57.1452172118909; Thu, 07 Jan 2016 05:08:38 -0800 (PST) Subject: Re: [geda-user] (SQL file open/save) To: geda-user AT delorie DOT com References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se> <20160106133049 DOT 5A0E9809D79B AT turkos DOT aspodata DOT se> <20160106143629 DOT 4D39D809D79B AT turkos DOT aspodata DOT se> <20160106164022 DOT D0D4E809D79B AT turkos DOT aspodata DOT se> <20160106180912 DOT 42ddf4079d91384f206b7c35 AT gmail DOT com> <20160106191433 DOT 5dc5cb59 AT jive DOT levalinux DOT org> <20160106202817 DOT 56197b2c539d426a1b724c9e AT gmail DOT com> <568E09ED DOT 1080508 AT m0n5t3r DOT info> From: "Sabin Iacob (iacobs AT m0n5t3r DOT info) [via geda-user AT delorie DOT com]" X-Enigmail-Draft-Status: N1110 Message-ID: <568E6354.80302@m0n5t3r.info> Date: Thu, 7 Jan 2016 15:08:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0kDj1Tl7Aes0qbeSQ5c5NtXXNRc3ow4uO" 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0kDj1Tl7Aes0qbeSQ5c5NtXXNRc3ow4uO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/07/2016 01:54 PM, Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > Okay. > > > I agree that first the data model shall be defined. some of it is already defined, right? it's a matter of cleaning up existing concepts and adding what's missing... talking with zero knowledge of the internals here, so don't take my word for it. > So you say we shall roll our own file format? "we" already have an "own" file format, there's nothing wrong with tailoring your data storage to your own needs; I, for one, would like to see at least named fields (syntax) and a coordinate system that makes sense (data model) > > On Thu, Jan 7, 2016 at 7:47 AM, Sabin Iacob (iacobs AT m0n5t3r DOT info > ) [via geda-user AT delorie DOT com > ] > wrote: > > On 01/06/2016 09:28 PM, Nicklas Karlsson > (nicklas DOT karlsson17 AT gmail DOT com = ) > [via geda-user AT delorie DOT com ] wrote: > >> On Wed, 6 Jan 2016 18:09:12 +0100 > >> "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com > ) [via > >> geda-user AT delorie DOT com ]" > > wrote: > >> > >>> Then it come to SQL can you solve file open and save as usual? > Or do > >>> you have to make connection to some kind of database? > >> Yes. SQLite. > >> > >> https://www.sqlite.org/ > >> > >> Using server/client architectured database engin like > postgresql is IMHO > >> overkill. > >> > >> Lev > > I used SQL once to write a small database application but I used > an SQL server and even though it works and could be done it will > be rather complicated for ordinary use. With a simple library > binding it could be worth a try. > > > > > > all right, can't stand it any more, I've been eating my words for a= > while now: please, please, please, stop with this SQL nonsense... > I know > that once you find a new shiny hammer everything looks like a > nail, but > schematics and PCBs are graphs at the core, and SQL databases are a= > pretty bad fit for storing graphs (yes, you can shoehorn them in - = see > mptt - but the results are more often than not awful); I too would > like > to see a more comprehensible file format for PCB, but SQL will be > anything but comprehensible (source: used SQL extensively for the l= ast > 15 or so years as a developer and a server babysitter). > > as far as file formats go, while something standard like json or > (cringe) yaml or (cringe even harder) xml would have advantages > (ubiquitous library support, easy-ish to parse and modify with awk = & > friends for people who are so inclined), it will degenerate into > unproductive holy wars (see previous pushes for lua as the file > format, > or various bickering about which text format is best); the way I > see it, > the process looks like this: > > * decide on data model; this is where you think hard about what > you need > to do, how it maps to the physical world, etc. > * decide on syntax, write formal grammar; this is where you take in= to > account parse-ability with standard text tools and human brains > (I, for > one, am a big fan of "design for humans first, computers later") > * have a parser generator generate parsers for every language you u= se, > generate some more as they are requested > > problem solved, you get canonical parsers for all languages that ar= e > needed and no extra layers of FFI (which can be needlessly heavy) > > --0kDj1Tl7Aes0qbeSQ5c5NtXXNRc3ow4uO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWjmNVAAoJEIIekQf3ltoLv34P/RCeVicUlcEDcrzSKZ/FHrCo kFKpHhi4MWs1FaPntn5DmWHkNWAWGnNLUDbcmot6vFJOZzgTVNsR1PdPt5EMFUn7 iAFRYlhD9AxmRw7CwHGi5vqTaHQZagzQwNPe3/cQdZHuXdB9kDNqhvmDEl2z+UxL oJzGisQFZwlYWM8BaWK49Asf6VYGxnBE/HrK7leFBFhtePb+8FSSc5NIKNf/TKjz FfvR/bqrm8mNwDtSqaDgYUCAwuRnsGyW+XBWKgHxIgVWNtLEwfZEF3eOBNktru/Y xLC/nXZgcCwf6IM6lyoXrfLxFLhaMTmnpfOXuciE7gzz7eZdXrAr4h/m9jVr9rh2 rjWyJADh9csGVKToD3K2KxxgKFOD1T/wyTPIGpP+eFkXtao7RrBP2L1sFZP1nOYt RNbN/5nR+am7YuPbZTBwNlD0X6Bbxv7lf53x0XJ29yaDo0L28mIO10msYaVE6pyJ 8uXc8Yo6/ZdIo/ACwLprfcpx+TCKdrS/yJVUhOpyl6NcL8VwbYEwlfZlXjBQ/nLZ e1ApBmHo8li3B8sJ549rKPZzHxJ2XHWUAGSr5B+tUJgV3VlxBMZtd10VOn/hsSvf njnbWm7M6VJ4u8N26fE3spu+OmPrR8rPxdDe6OdLJhvUr2a5VEhWN7R6siyxfAW6 EgOyUKN//IWurwxFPt2C =dJux -----END PGP SIGNATURE----- --0kDj1Tl7Aes0qbeSQ5c5NtXXNRc3ow4uO--