X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Thu, 24 Dec 2015 01:26:56 -0500 Message-Id: <201512240626.tBO6QuW0031998@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: <0AB5D926-731F-4A49-AA26-D06DAE7C2CB0@noqsi.com> (message from John Doty on Wed, 23 Dec 2015 14:51:26 -0700) Subject: Re: [geda-user] A fileformat library References: <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <20151223194905 DOT 7676 DOT qmail AT stuge DOT se> <0AB5D926-731F-4A49-AA26-D06DAE7C2CB0 AT noqsi DOT com> 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 > I think that having a file format that enables simple means to > achieve simple (but specialized) ends is essential to a good > toolkit. Any SQL implementation refutes that. Nobody touches the SQL data file itself, they all go through a SQL interpreter that accesses the data on their behalf. Specialized ends are implemented on top of this interpreter. Granted, this means we'd need a well-defined way to do pretty much anything through whatever means we provide, but saying "access to the file is required" is just plain wrong. "Access to the data" is a more appropriate requirement, but making the data file tweakable is a weak solution to that - no controls, no validation, etc.