From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262123AbTJ3EWJ (ORCPT ); Wed, 29 Oct 2003 23:22:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262126AbTJ3EWI (ORCPT ); Wed, 29 Oct 2003 23:22:08 -0500 Received: from lvs00-fl-n13.valueweb.net ([216.219.253.195]:54248 "EHLO ams013.ftl.affinity.com") by vger.kernel.org with ESMTP id S262123AbTJ3EWG (ORCPT ); Wed, 29 Oct 2003 23:22:06 -0500 Message-ID: <3FA091BD.2020701@coyotegulch.com> Date: Wed, 29 Oct 2003 23:21:17 -0500 From: Scott Robert Ladd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2 X-Accept-Language: en MIME-Version: 1.0 To: trelane@digitasaru.net CC: Alex Belits , Dax Kelson , Hans Reiser , andersen@codepoet.org, linux-kernel@vger.kernel.org Subject: Re: Things that Longhorn seems to be doing right References: <3F9F7F66.9060008@namesys.com> <20031029224230.GA32463@codepoet.org> <3FA0475E.2070907@namesys.com> <1067466349.3077.274.camel@mentor.gurulabs.com> <20031030002005.GC3094@digitasaru.net> <20031030031223.GA15309@digitasaru.net> In-Reply-To: <20031030031223.GA15309@digitasaru.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Joseph Pingenot wrote: > Actually, the point isn't to be Microsoft-compatible; rather, it's to > aid in the indexing of information for quick search and cross-reference > (their thrust at the 'knowledge worker'). Exactly. In my experience the most significant problem programmers face is inventing a system for categorizing and organizing information. I have 20 years of collected data on everything from fly fishing to solar sails; lord knows I can't ever find anything, no matter how carefully I organize my directories. Another problem with metadata is that it is largely generated by the user, who is notoriously lazy. A truly powerful system would use contextual analysis and other algorithms to automatically generate metadata, freeing the user from an onerous task (which is what computers should do). Certainly, some search engiens are bordering on this capability. > Well, the point of making this a modular userspace daemon is that we don't > *have* to dictate any such thing. The idea is that writes could be > piped through the indexing daemon, and the daemon would then have plugins > that understand *different* formats. Optionally, I suppose, one could > add a new open() flag to say "don't index this". I've been working on a daemon that actively examines and updates metadata, similar to a web-indexing spider, but more directed; the metadata is then stored in "spatial" structures such r-trees or M-trees (this daemon is very experimental at this point, and I'm still exploring structures and algorithms). > Indeed. Couldn't agree more. That's why we should create *infrastructure* > for such an indexing service, and allow the community to create plugins > as needed. A wise approach. -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Software Invention for High-Performance Computing