From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 17:01:25 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C185816A403 for ; Fri, 11 May 2007 17:01:25 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4969B13C458 for ; Fri, 11 May 2007 17:01:25 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HmYUP-0004oK-6V for freebsd-hackers@freebsd.org; Fri, 11 May 2007 19:01:09 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 May 2007 19:01:09 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 May 2007 19:01:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 11 May 2007 19:00:41 +0200 Lines: 68 Message-ID: References: <200705102105.27271.blackdragon@highveldmail.co.za> <4643C7DB.6000408@elischer.org> <17988.35412.231093.411177@bhuda.mired.org> <17988.40311.210855.381093@bhuda.mired.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF3CBC1EA99334E21A7E11CAB" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <17988.40311.210855.381093@bhuda.mired.org> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: SQL in the base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 17:01:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3CBC1EA99334E21A7E11CAB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Mike Meyer wrote: > Yes, they are present no matter what representation you use. The > question is - how do the answers change if you change the > format. These days, cross-platform means you deal with length as well > as endian issues. Or maybe you don't, depending on the db. I know the > answers for text files (easy, easy, very, yes). Can you propose a db > scheme that gets has the same answers? I think I don't understand the question. If the database contains number = "42" in a field typed "int32", in a row, and handles endianess well, why = would I get a different number on different platforms? (A side note about sqlite: it's actually weakly typed - you store and=20 receive strings). > I hate to tell you this, but your XML solution would still consist of > a bunch of one-of file formats for each and every purpose. Using XML > just fixes the syntax for the file, not the semantics. Settling on XML > (or JSON, or INI, or cap files, or ...) is sort of like settling on > UTF, only less obviously a win. Sure, you get to use canned code that > will turn you text file into a structure in memory. But you still have > to figure out what it all means. >=20 > As you say, the XML toolset is the real win. Smart editors, > validators, schemas (which make the editors and validators even more > powerful) are all good things. Most people don't really seem > interested in this beyond editors. That's not really much of a win. I agree that validation in XML is a strong point - but one of the reason = people like text files is that they DON'T usually have validation=20 features :) | pro | contra ---------------------------------------------------------------------- XML | standard tools, validation, | evil manual parsing, bad rep | can embed multiple data | | structures in a standard way | ---------------------------------------------------------------------- text | standard tools, sometimes | no validation, manual parsing, | human readable | usually one data structure per | | file --------------enigF3CBC1EA99334E21A7E11CAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGRKE5ldnAQVacBcgRAvLpAKDAshAiP7IZW3RFYZLQ6SHMd6oKJgCgjgQj emQqM6aQhwfS+Rlh8duNq2k= =iJpD -----END PGP SIGNATURE----- --------------enigF3CBC1EA99334E21A7E11CAB--