Re: [HC Evolution] Re: libole2 -> gnomevfs backend?

notzed wrote:
Uh?  Why would a user want to?  Hiding it in a single file just
makes it impossible to edit or understand (or fix, or
troubleshoot, etc).

An end-user should not fix, troubleshoot, or edit internal Evolution data.
That's our job.

However, this being a free software project, there will be at least
a stage where this is useful.

A programmer could do this, however, if the file had a simple hierarchy of
'files' within it (like libole2). Heck, Nautilus could probably explore it
(given a "view as.." menu item selection).

Well, or they could use less and emacs and bash?

Hmm, i can see which is easier here.  Why not just give them regedt32.exe,
and be done with it?

If a user has to worry about automatically created any file at all,
then its already too complicated.

People are comfortable with files. Having a single file which represents
everything that Evolution and the Wombat needs, does not seem complicated to
me; on the contrary, it's quite simple for the user. And it seems pretty
simple for the programmer, if our file has a hierarchy of things within it.

And if you double-click on the file, Evolution fires up. From the desktop
user's point of view, this is a data-centric (rather than
application-centric, where you have to run Evolution to load your data) way
of doing things.

Uh?  Ideally the user shouldn't even see it cluttering their filespace.

"save settings as" seems to work
pretty well, or in a real enterprise environment their settings will
be on nfs, or in a central server (e.g. ldap), so they definetly
will not need to be copying any config file.  Stop thinking
like a windoze user.

Yes, there is a server which will hold the settings of the user; it's called
the Wombat. It can save the view-related settings into our consolidated
file. :)

No, thats different, thats a personal server, not an enterprise server.

Doesn't really make any differnece if you ahve the interface.  A lot
of little files is a pain to program, without the config api you'll
have anyway.

I'm saying the storage mechanism has nothing to do with the api.

The api is what the programmer uses.

Not sure exactly what you mean here. A web client will have to get at the
list of folders (or uri's), and they'll need to get them from the wombat.
That's the point of the wombat: a place that keeps track of all that's
personal to one user (at least wrt mail/calendaring/addressbooking), and
exposes it. But again, I'm not sure exactly what you meant here, so maybe
I'm missing the point.

Now, as Miguel pointed out, there's a lot to do, and it's possible that we
won't be able to consolidate everything immediately. But I think it's a good
goal to have.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]