Re: Moving away from app-centric mimetypes (e.g. kword)
"Friedrich W. H. Kossebau" <[email protected]> Sun, 19 May 2002 18:05:52 +0200
| Newsgroups | gmane.comp.kde.look |
|---|---|
| Message-ID | <[email protected]> |
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? > 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? > * the ability to query specific documentation > * the ability to query RELATED documentation Please, could you give an example for both? > * 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? > * 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 :) Thank you Friedrich