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

List:       kde-look
Subject:    Re: File management (long)
From:       Marko Samastur <markos () elite ! org>
Date:       2000-03-26 19:29:50
[Download RAW message or body]

Hi,

I'm sorry for late reply, but I just got back from my trip to UK.

Alistair Bayley wrote:
> 
> have you read the Alan Cooper article "Digital Soup":
> 
> http://www.cooper.com/articles/vbpj_digital_soup.html

I did now, but I've read his About face before that and my first idea
which (will) became Docas proposal, was based on ideas I got from there.
 
> This seems to be a similar thing to your Document Assistant proposal.
> 
> I don't think that Docas should be creating extra files on the file system; rather, \
> they should go in its own database (a bit like RPM has its own database). I think \
> that Docas should be able to extract meta-info from files where it is present (for \
> example, from HTML/XML or MS Word docs), and have the user provide it where not \
> present (or inferred from file extension/magic bytes).

Yes, it is similar, but it's not all of it. Part of Docas (as you've
mention it later on) is also revision control, which is not a subject of
Alan's paper.

However, I do think Docas will need to create extra files. I think
Thomas has the right idea, when he wants to store permanent information
in xml files and create basically in-memory database. Running database
is needed for speed, but as Thomas already pointed out, it isn't easy to
insert new record types, which can be very easily done in xml
configuration files.

If you keep this meta-information files separate from other files
(similarly hidden like tree behind .kde), it shouldn't bother anyone.
Especially if it's you who creates an interface between documents in
file system and their representation to the user.

You are right of course, that information should be gathered from the
files whenever it is possible and as much as possible, but I don't see a
reason against offering users the possibility to create/change it on his
own.

The goal is to get a flexible system which would offer the user to
categorize and retrieve documents the way he wants. I haven't seen Lotus
Notes yet, but I do plan to do so before as part of my investigation. 
 
If it wants to be useful, it should do as much as possible on its own
(meaning gathering different information, categorizing etc.), but
shouldn't stand in users way of doing things (its design should limit
users possible actions as much as possible).

> I know that KDE is deployed on non-Unix systems, but again I think that users \
> shouldn't have to know about their particular system's file structure. My family \
> are often saving documents under the Profile directory on NT (this is because of MS \
> Word's default setup), which annoys me because they each have their own directory \
> (on another drive) for their work, much like /home on Unix. They really don't care \
> where the files go, just as long as they can open them again when they click \
> File->Open.

I think we all agree on that. File systems are a fine way to organize
things for programmers, but they are really something users shouldn't be
bothered with if they don't really want to.
 
> And on the revision/history thread:
> I was wondering if Docas could include revision browsing. This may go some way to \
> solving the problem of presenting revision control to the user. I'm still not sure \
> how applications should handle it though. They will have to be able to cope with \
> opening a given file, or opening a file at some point in the revision history.

The plan was definitely to have revision control and Rik already showed
the way how it could be done in non GUI kind of way. It certainly seems
to make sense to me to include revision control because otherwise you
loose valuable information (for example, different authors of different
revisions) and limit the power of retrieval system.

As others I also don't see a reason why there should be two browsers. I
don't see why Konqueror couldn't  be adapted to it.
 
> I guess we'll end up with a system that has two browsers: one is the raw filesystem \
> browser (Konqueror) and the other is Docas, which organises files in ways \
> meaningful for the user.

I think Alan has some nice ideas, but that he isn't very consistent in
this particular article. I also think he is sometimes wrong (as Thomas
has pointed out already). I do think we started on the right side of the
problem, because the basic premise from which we started the whole
discussion was how to give a user a better way to work with and RETRIEVE
documents. Other ideas (about storage etc.) came later on and were
basically something that was offering itself quite naturally.

We also haven't discussed implementation that much as we did the
functionality and even when we were discussing particular technology
that could be used, it was in view of already established goals and not
vice versa. Actually we mostly discussed thing up until now  and we will
probably do more discussion than implementation in the immediate future
too.

I certainly don't plan to start programming before the end of April or
start of May and until then I do plan to look at Notes more closely,
gather all the ideas in one document and only then start to work on
things, that we agree on.

Greetings,

	Marko


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