[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Moving away from app-centric mimetypes (e.g. kword)
From:       Dave Leigh <dave.leigh () cratchit ! org>
Date:       2002-05-20 2:28:08
[Download RAW message or body]

On Sunday 19 May 2002 11:05, Friedrich W. H. Kossebau wrote:
> Dave Leigh schrieb:
> [SNIP]
>
> > The resulting problems included (obviously) revisions to documentation,
> > but also locating associated projects that (proposed or implemented) that
> > impact mine. For instance, if I want to make a change to the Business
> > Rules Engine, as part of my analysis I need to see every existing
> > proposal that affects the files I propose to change. Current approaches
> > to this require specialized (i.e. expensive) skills to do the ERP.
>
> Just for the record: What stands ERP for?

I intended it to mean the product planning aspect of enterprise resource 
planning. My clients have typically used the term to include the planning and 
management involved in the development and modification of software resources 
(including services) as well as hardware resources. Other organizations 
broaden it to include everything from purchasing to customer service to 
making coffee, but I meant the planned management of software resources 
associated with development within the enterprise.

> > Among the possible benefits of this approach are:
> > * support for revision control for every file in the system. It doesn't
> > require training or approval of a business unit, because it's mostly
> > transparent to them. They're already used to seeing a message when
> > someone else has access to a file... they'd simply be able to see this
> > directly in Konqueror... they could check in and out, and see a
> > properties tab that could show revisions.
> > * the ability to do full-text indexing on a filesystem
>
> Pardon, how do you think this to be implemented? With one big central
> database where the indices are updated with each save/synchronisation of
> a file? Or with the word indices stored in the metadata of a file so a
> search has to scan through all metadata?

Primarily the focus of this list is the possibilities and the user-centric 
aspects of those possibilities. Implementation isn't a primary focus. That 
said... if the filesystem is a database, then it can be implemented the same 
way that full-text indexing is done with conventional databases today. 
There's nothing to invent here. The database itself doesn't have to be 
invented either. The suggestion was to take a conventional database and 
provide an interface to make it appear to be a filesystem. 

In any event, it's important to understand WHAT you'd like to implement 
before constraining yourself with an actual implementation. My discussion 
relates to what I'd consider an ideal system in the environment in which I 
and others like me work. I DON'T necessarily consider it to be an ideal 
system for home users, lone developers or very small shops.

> > * the ability to query specific documentation
> > * the ability to query RELATED documentation
>
> Please, could you give an example for both?

Sure. 

A query of specific documentation simply returns the file requested. You 
don't need to know the location of the file because, as the filesystem is a 
database, it can be indexed in more than one way. One possible index ignores 
the path and indexes only the filenames. 

Query of related information could retrieve all files residing in a directory 
tree, or which are referenced by a specific file, or which contain metadata 
matching the criteria given the query. Previously I used a natural language 
example that went something like "Retrieve all recipes containing portabello 
mushrooms or lamb." In this there is a command ("retrieve") a keyword 
("recipe") that might be pulled from metadata, and data retrieved from a 
full-text index "portabello" "mushrooms" and "lamb".

You can do all of this with a conventional search utility. HOWEVER, if you've 
ever dealt with a large organization where you've got a couple of hundred 
developers creating code, several dozen designers and architects churning out 
literally hundreds of designs per year, then you realize after you first 
search that a conventional search utility SUCKS at the task. It's like trying 
to move a hill with a tablespoon. It can be done, but you're better off using 
a bulldozer. The conventional file search is useful for the tiny volumes of 
information generated by an individual or a very small shop, and can take 
hours on the volume of data we've had to work with. An indexed database with 
a proper search engine can do the same task in seconds.

> > * the ability to replicate portions of the file system without regard to
> > the hierarchal directory structure.
>
> Oh dear, I don't get anything. How is this related?

It's related in being a potential benefit of using a database as file system.

The ability to perform the query and generate a result set quickly is only 
the first benefit. Another benefit is the ability to do more with that result 
set once you have it. Lotus Notes administrators have long been accustomed to 
the benefits of being able to replicate databases to geographically separated 
servers to improve the response time for local users. Telecommuters can do 
*selective* replication to work locally with a subset of that database. They 
can then work locally with shared files without fear of stepping on each 
other's work (since replication includes conflict resolution).

The point is that once you talk about the filesystem as a database, there are 
a boatload of VERY useful, VERY important features that are not immediately 
obvious to individual users, but which are wonderful from the standpoint of 
system administrators and telecommuters.

> > * the ability to concentrate on your specific job rather using existing,
> > unmodified tools rather than on some monster system to store all this
> > stuff. Directories, for example, can be given default metadata that are
> > inherited by any file created there. The file can then retain those
> > metadata even if moved within the filesystem. The act of moving the file
> > could impart new metadata, so that a single file could be of multiple
> > "kind."
>
> Where could this imparting of new metadata be useful? Pardon, give us
> please another example :)

No problem. I begin working on a system on a project to create a "Field 
Validation Engine" for whatever reason. It's originally sponsored by the 
eBusiness manager to support one of his projects, and it starts off in an 
eBusiness directory. The metadata associated with the files in this directory 
reflect its role as an eBusiness service. At a department meeting the concept 
is discussed and some other managers decide that it's something they'd like 
to include in their projects as well. Because this will mean changes to 
generalize the design so it's usable by projects other than eBusiness, the 
ownership is transferred to the Software Infrastructure manager, and the 
directory is moved as well. It now inherits metadata reflecting its new role 
as a Software Infrastructure project. But this doesn't change what it was, 
and anyone searching for it using the old criteria would also find the same 
project.

> Thank you

You're quite welcome.

-- 
Dave Leigh, Consulting Systems Analyst
Cratchit.org
  http://www.cratchit.org
  864-427-7008 (direct)
  AIM or Yahoo!: leighdf
  MSN: leighdf29379@hotmail.com
  ICQ: 37839381

One of the pleasures of reading old letters is the knowledge that they
need no answer.
		-- George Gordon, Lord Byron

[prev in list] [next in list] [prev in thread] [next in thread]