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

[NotZed <notzed helixcode com>]

> 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.
>
> -Matt