Re: Moving away from app-centric mimetypes (e.g. kword)

On Tuesday 14 May 2002 12:40, Sven Niedner wrote:
...
> Then, as a reference implementation, I would suggest an MySQL ioslave,
> storing files as blobs and the properties in a database. These files
> are only accesible by KDE ioslaves, OK -- but this is a good starting
> point. When the filesystems are ready, the file: ioslave could follow,
> and other ioslaves as well. One also has to rethink the concept of a
> hierarchical directory tree and look for useful extensions. Designing
> such a thing "from scratch" is a fascinating task, and it would be cool
> if something like this could run in alpha quality on KDE before M$ gets
> it patented :-). It would be a good idea to look for present research
> in the CS community on the problems.
...
> So far my ideas on extended attributs and storage systems of the future,
> 
> Sven.

I must admit that I agree with this in large part, but I DO NOT think that 
this should begin as a KDE thing. The VFS should come first, with KDE support 
for it as a possible parallel project. I also think that it's a best used a 
solution in the enterprise file server arena.

Here's a real-world example where something like this is extremely useful. At 
my last major client, they used a method of storage for project documentation 
that was extremely low-tech... they simply stored project documentation in a 
directory structure. While this satisfied the requirement to store the data, 
it was practically useless for the RETRIEVAL of that documentation. I beat my 
head against the wall for four years trying to convince people that 
documentation properly belongs in the revision control system, right along 
with the project code. Never happened. While a number of the IT guys 
understood the necessity it was impossible to get the Business Analysts and 
Business Units to sign on (too complicated). 

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. 

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
* the ability to query specific documentation
* the ability to query RELATED documentation
* the ability to replicate portions of the file system without regard to the 
hierarchal directory structure.
* 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."

Now, while I'm primarily concerned with enterprise-level development the same 
sort of abilities are equally useful elsewhere; for example, in publishing.

It's been awhile since I've been directly involved with Oracle as anything 
other than a straight database server, so I'm not aware of what they've 
already provided in this area. But while we're talking about IOSlaves, IMHO 
it's equally important to support the Oracle solution as it is to come up 
with a free alternative using MySQL or PostgreSQL. No doubt it would be 
faster to come up with an IOSlave for an existing filesystem implementation 
of this type (such as Oracle) than it would be to come up with the free 
implementation first; then it would be a matter of constructing the free 
implementation to provide similar capabilities.

Obviously, all of this can be pretty huge in terms of storage, and it's 
overkill for the average user. But it DOES solve a number of problems for 
enterprise users. I still think that Friedrich's original problem is best 
addressed by simply extracting existing metadata from existing file formats 
and improving the file preview.


-- 
Dave Leigh, Consulting Systems Analyst
Cratchit.org
  http://www.cratchit.org
  864-427-7008 (direct)
  AIM or Yahoo!: leighdf
  MSN: [email protected]
  ICQ: 37839381

And on the eighth day, we bulldozed it.