From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 05:14:13 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 26C5016A403 for ; Mon, 14 May 2007 05:14:13 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id 0271613C44B for ; Mon, 14 May 2007 05:14:12 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l4E5E7MK031471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 May 2007 22:14:07 -0700 X-Auth-Received: from [192.168.10.45] (c-67-174-148-212.hsd1.ca.comcast.net [67.174.148.212]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l4E5E6hg016876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 May 2007 22:14:07 -0700 Message-ID: <4647F016.1070200@u.washington.edu> Date: Sun, 13 May 2007 22:13:58 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ivan Voras 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.5.13.215934 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: freebsd-hackers@freebsd.org 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: Mon, 14 May 2007 05:14:13 -0000 Ivan Voras wrote: > 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 > 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. >> >> 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 > 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 > > I assume that many Database formats have functionality to convert to 'system independent' endianized fields when flushing the database to disk. That's what BDB does at least (I think that the endianness used is little endian). -Garrett