Re: [Evolution-hackers] Configuration masquerading Data

Hi Gilles,

> first, let me tell you I perfectly agree with you that user data should
> be easily accessible to users. It's their data after all.

It's not just abut accessibility in your currently working computer at
this point in time. It's also about visibility, compatibility with
alternative and future programs, the ability to use these files in
interesting way. Do we have a program that can give you real time
reports on your emails? do we have innovation in data processing? I
beleive hiding the data has lead everyone down the garden path,
restricting compatibility, reducing the drive for standardisation and
ensuring programmers have lots of work to do in the import and export
plug-ins market.

> Now I want to shade this a bit for what is usually called PIM data.
> imho, users (I mean normal non-geeky users) often only know about one
> way of getting to their data and can only handle few at a time.

Dealing directly with how the user interfaces is an important
question, but I believe we must enable as many routes to use our data
effectively with the way we structure our output. For instance I don't
believe someone will check their emails in nautilus. But could they do
a search or open those self same emails in kmail without syncing and
api bridging crutches? Could they access their email in a command line
tool? is there a way to send a message in a business account on
evolution as an attachment in your gmail account?

> This is really important wrt to what you said about mails. Somebody replied to
> this thread qualifying what would be the direct (brutal) application of
> your proposal as a tsunami of data and I can only agree with that. This
> would be a poor user experience really :)

Well only if the emails were all pushed into their face, say if we
store them all in ~/, I'm not advocating bad design. Picking out the
ideal structure for where emails go which is out of the way but still
available is important. The suggestions I've given already make it
clear that the system is just as important as the principle to make
sure we don't introduce new problems.

> About standards, evolution actually uses standards to store data, mbox
> for mails, ics/vcard for addressbook, events & memos.

this is good, if EDS is already using these files then it's not much
of a change to make it configurable and/or based on XDS directories
(which distro's could then configure) giving users, distributors and
other programmers ways to find and control data output in what ever
way they feel their target users would like.

> It can also export
> all of these data from their hidden store to another standard format.
> Even nicer, it has a backup plugin that saves all this and configured
> accounts to a tarball that you can save anywhere you want. Personnaly
> I've had harder times getting my data out of thunderbird last time I
> tried (which was probably ~1.0).

Lots of exports are band-aids, some exports are genuinely useful such
as svg to pdf, going from editable design stage to print ready
production. others are for compatibility or for backing things up.
Exporting an email to a processed thread file would make sense I
think. Exporting it to an email backup file seems like it's trying to
get around the limitations of the user data storage, because if normal
backup solutions can't back your emails up without making special
exceptions to decided what is data and what is configuration for every
app it's not doing something right.

> Now obviously all programs probably won't be able to deal with
> evolution's backup tarball (but most probably can with "individual"
> exports) but that's probably because nobody even thought about getting
> started on standardizing this kind of stuff before.

If you made a backup using a standard file backup utility when using
the proposed ideas; you would be able to recover the emails in the
right directories ready for use, even if during the time you had moved
applications or even platforms. In fact there would be no thought
needed from the user, it would be a simple matter of getting the files
in the right places.

As for opensync, could you imagine if they could eliminate all those
custom end point plugins for each and every application?

Best Regards, Martin Owens

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