Re: [Evolution-hackers] Configuration masquerading Data

2008-09-23 Thread Felix Kaser




Examples:
 - Pidgin
 * Configuration - Settings for which services to connect to, what
skins to use and what plugins to use.
 * Data - Text entered at the keyboard, text received over the
service, files received or sent over the service, chat logs.

 - Gnome Background Settings
 * Configuration - which background is selected, which backgrounds are
available, how a background is to be presented.
 * Data - Background image files

 - Evolution Email Application
 * Configuration - which services to connect to, which plugins to use,
syncing rates, display preferences.
 * Data - Email messages recieved, contact data, calendar event, note
text, text typed in, files sent as attachments.
  


Ahhh wait! It's nice you separated data and configuration, but to be 
honest: I really don't want my home directory to be flooded with data I 
don't even want do see outside the application! I don't want to have a 
folder background images in my home where the background images are, I 
don't want to have a evolution emails folder where I can get to my 
emails without opening Evolution itself! I don't think I'm alone with 
this thought...think of all the non-power-user, for them it would be a 
tsunami of data they cannot handle...


The idea is nice, but not for every program! Why should I want to access 
the emails directly? I can use Evolution for that, its nicer and a lot 
more user friendly then the file explorer is! I think this is a big step 
in the wrong direction, you would like to use the email application just 
to make the connection and download the mails! That reminds me of the 
old telnet email clients - my uncle still uses one of them, because he's 
familiar with that - but we have really powerful applications now, we 
should use them!



  

What I'm asking is, at which point do you think the line between
application data and user data needs to be drawn, or do you think that a
best practice approach might incorporate the idea that if your
application stores information that is useful to another application, it
should be stored in a non-configuration location?



There is a further separation at the configuration level which must be
accounted for. Sercive configuration often involves standard protocols
which multiple different apps for different reasons could use the same
configurations for. This isn't to be confused with user data though. A
directory for ~/.services/email/accounts.xml would be a way of
standardising the service/protocol level configuration.

User data though needs to be stored in ways which users have control
over directly. The cheese project recognised that keeping photos out
of the home directory browsing space was a bug and that hiding user
data is not a desirable quality when you want flexibility and user
control. The fact that other applications could use this data is a
useful side effect too.

For instance using XSD directories cheese has allowed F-Spot to be
made to import photos from the XDS directory, grabbing cheese photos
and then allowing the user to export them to flikr or what ever the
user wants. This provides a level of context to a users data and power
to the user.

The XSD directories idea is a very powerful one which should be
considered for more user data than it is currently.

Another aspect is making sure that each elemental datum has a standard
format which we can use to allow the user control of. For instance an
image can be saved as a png file, An email message can be saved as an
eml/message file and a bookmark can be saved as a link file. but not
all of the available formats have been agreed upon, standardised or
even meet all of the feature requirements of the applications
involved. For instance vcards are nice, but I can't see EDS using them
as a data store since it's not a very normalised format.

I should also make a note that just because the data is stored in
files in some of these examples doesn't mean you are forced to forgo
the use of an index. The mechanism of recording your email messages in
a sqlight db file which may or may not be specific to the application
is not in question.

Let me know if I've managed to explain my ideas on how we can
differentiate user data from configuration data. I'd be interested in
cases which break my logic.

Best Regards, Martin Owens
___
Cheese-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/cheese-list

  


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-23 Thread Felix Kaser

Martin Owens schrieb:

Dear Felix,

  

Ahhh wait! It's nice you separated data and configuration, but to be
honest: I really don't want my home directory to be flooded with data I
don't even want do see outside the application!



Calm down dear, it's only a discussion.

  

I am calm =) Sorry if it looked like I'm agitated or something ^^


Now I think your idea is not bad at all, because we have a quite nice
folder structure already (Documents, Pictures, Videos and so on). But
they must be used! Correct me if I'm wrong, but FSpot makes its own
directory (/home/foo/Photos) for the pictures you want to copy to
picture location (you can select this option when importing pictures to
fspot).

I still see some issues (like a unified way to save emails, not that if
I first use Thunderbird my emails are stored like foo.mail and with
Evolution they are stored like 080916_foo.evomail or similar) but
issues are here to resolve and as you pointed out already: this is a
discussion, so lets discuss :)

Martin, are you familiar with Cosimo Cecchi's Summer of Code project?
(http://code.google.com/soc/2008/gnome/appinfo.html?csaid=15C2B5BC19A9276A)

Probably a integration of his media manager into nautilus would solve
some of your problems?

cheers
felix

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-18 Thread Martin Owens
Dear Felix,

 Ahhh wait! It's nice you separated data and configuration, but to be
 honest: I really don't want my home directory to be flooded with data I
 don't even want do see outside the application!

Calm down dear, it's only a discussion.

 I don't want to have a
 folder background images in my home where the background images are, I
 don't want to have a evolution emails folder where I can get to my emails
 without opening Evolution itself! I don't think I'm alone with this
 thought...think of all the non-power-user, for them it would be a tsunami
 of data they cannot handle...

I don't think it would be that much of a 'tsunarmi' not only would
defaults be selected in a way which would make them structured and
shared; but they would be configurable (even to the point of hiding)
and wouldn't exist until you needed them anyway.

 The idea is nice, but not for every program! Why should I want to access the
 emails directly?

Why wouldn't you want to? 1) Backup your emails without special
software, 2) Be tied to a specific program for the rest of your life
with special syncing software. 3) Unable to index emails without
special indexing software. 4) Be able to search for emails without a
searcher that integrates with said indexing software 5) Be able to
input and export to and from other services and devices without
special software.

In fact one of the themes of the above is that for every innovation
you need to have special software which interacts with the application
APIs or hidden proprietary formatted configuration files in order to
do anything interesting. It's a lot of wasted work which only comes
about because developers think it's nice to want to hide their user's
data.

 I can use Evolution for that, its nicer and a lot more user
 friendly then the file explorer is! I think this is a big step in the wrong
 direction, you would like to use the email application just to make the
 connection and download the mails! That reminds me of the old telnet email
 clients - my uncle still uses one of them, because he's familiar with that -
 but we have really powerful applications now, we should use them!

So be it, no one said these folders couldn't be hidden in a teletubby
distro for those who are weak of heart. As far as a step in the wrong
direction I think not: the underlying technical principles set forth
in my previous emails would be valuable, if employed in an integrated
manner. they would allow people to move from/to gnome/kde/xfce without
having to sync data, it would allow programmers far more stability
and confidence in how to access various types of data, creating a
platform for more interesting ideas to be tried out.

Oh and most people end up creating a backgrounds folder anyway.

Best Regards, Martin Owens
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-18 Thread Martin Owens
Hi Felix,

 Now I think your idea is not bad at all, because we have a quite nice
 folder structure already (Documents, Pictures, Videos and so on). But
 they must be used! Correct me if I'm wrong, but FSpot makes its own
 directory (/home/foo/Photos) for the pictures you want to copy to
 picture location (you can select this option when importing pictures to
 fspot).

Yes that is the case, the way these directories are configured is that
there is a config file which lists each one. this allows for folders
in different languages to be used correctly by programs without having
to have that foreign language support built in (without breaking
horribly). Getting folders used is a matter of project preference,
although support for the ideas from other developers would help push
standards too.

 I still see some issues (like a unified way to save emails, not that if
 I first use Thunderbird my emails are stored like foo.mail and with
 Evolution they are stored like 080916_foo.evomail or similar) but
 issues are here to resolve and as you pointed out already: this is a
 discussion, so lets discuss :)

The file names them selves might not be such a problem so long as the
structure is well defined. Making sure the folder structures in
evolution correspond to the folders in the file system would be a
first step. This may either be done through convention or by
configuration (such as a more detailed XDS) The file formats and the
mime-type would be the most important aspects after structure.

E.g ~/Email/Personal Account/Inbox

 Martin, are you familiar with Cosimo Cecchi's Summer of Code project?
 (http://code.google.com/soc/2008/gnome/appinfo.html?csaid=15C2B5BC19A9276A)

It's a very interesting project, it actually seems more radical than
my ideas but certainly is along the same lines. Having an index based
file chooser is a very useful feature.

 Probably a integration of his media manager into nautilus would solve
 some of your problems?

Although the main aspects of being able to run your files through any
application outside of gnome is still very attractive. ergo: ssh from
your laptop to your computer, your looking for a contact in your
evolution account. You have the command line.

P.S. I've taken cheese mailing list off the reply, don't want to flood
their list.

Best Regards, Martin Owens
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-18 Thread Gilles Dartiguelongue
Hi,

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.

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. 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 :)

About standards, evolution actually uses standards to store data, mbox
for mails, ics/vcard for addressbook, events  memos. 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).

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.

-- 
Gilles Dartiguelongue [EMAIL PROTECTED]


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-18 Thread Martin Owens
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
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-17 Thread Martin Owens
 I think this idea is extremely valuable and merits robust discussion to
 discover ways to encourage application developers to incorporate this
 way of approaching data storage.

Thank you, I'm not always as coherent as I'd like when I describe my
ideas and knowing it made sense to you gives me confidence in
presenting it as a discussion at UDS in December.

 I wonder how would you differentiate between data and configuration if
 you were to write a specification for this?

There is a logic between the two can be broken down into the following
definitions:

Configuration - Data which changes the state and logic of a
computation, key selection of the flow of an application or execution
which are not involved in the input or output data directly.
User Data - Data which is directly the input or output results for any
computation or use.

 Consider for example Pidgin, which stores its account data within a
 .purple directory. The same tree also contains logs for each of the
 discussions, icons, application preferences and miscellaneous other files.

Examples:
 - Pidgin
 * Configuration - Settings for which services to connect to, what
skins to use and what plugins to use.
 * Data - Text entered at the keyboard, text received over the
service, files received or sent over the service, chat logs.

 - Gnome Background Settings
 * Configuration - which background is selected, which backgrounds are
available, how a background is to be presented.
 * Data - Background image files

 - Evolution Email Application
 * Configuration - which services to connect to, which plugins to use,
syncing rates, display preferences.
 * Data - Email messages recieved, contact data, calendar event, note
text, text typed in, files sent as attachments.

 What I'm asking is, at which point do you think the line between
 application data and user data needs to be drawn, or do you think that a
 best practice approach might incorporate the idea that if your
 application stores information that is useful to another application, it
 should be stored in a non-configuration location?

There is a further separation at the configuration level which must be
accounted for. Sercive configuration often involves standard protocols
which multiple different apps for different reasons could use the same
configurations for. This isn't to be confused with user data though. A
directory for ~/.services/email/accounts.xml would be a way of
standardising the service/protocol level configuration.

User data though needs to be stored in ways which users have control
over directly. The cheese project recognised that keeping photos out
of the home directory browsing space was a bug and that hiding user
data is not a desirable quality when you want flexibility and user
control. The fact that other applications could use this data is a
useful side effect too.

For instance using XSD directories cheese has allowed F-Spot to be
made to import photos from the XDS directory, grabbing cheese photos
and then allowing the user to export them to flikr or what ever the
user wants. This provides a level of context to a users data and power
to the user.

The XSD directories idea is a very powerful one which should be
considered for more user data than it is currently.

Another aspect is making sure that each elemental datum has a standard
format which we can use to allow the user control of. For instance an
image can be saved as a png file, An email message can be saved as an
eml/message file and a bookmark can be saved as a link file. but not
all of the available formats have been agreed upon, standardised or
even meet all of the feature requirements of the applications
involved. For instance vcards are nice, but I can't see EDS using them
as a data store since it's not a very normalised format.

I should also make a note that just because the data is stored in
files in some of these examples doesn't mean you are forced to forgo
the use of an index. The mechanism of recording your email messages in
a sqlight db file which may or may not be specific to the application
is not in question.

Let me know if I've managed to explain my ideas on how we can
differentiate user data from configuration data. I'd be interested in
cases which break my logic.

Best Regards, Martin Owens
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-17 Thread Martin Owens

 Hi,

 I think it would be important to distinguish between a local cache of a
 remote IMAP or CalDAV folder (i.e. Configuration) vs. local mail
 folders, calendars, contact lists, etc. (Data).


I agree, I regretted not making a note about cache data. Caches are
temporary stores, if it makes sense to export them to a more permanent
states then that would be where they'd translate into user data.

As an example, pidgin's user lists and profile images are cache,
unless the contact is tied to a standard address book system where the
profile image could be stored in the right place it's not permanent
and is more of a state of the application.

Best Regards, Martin Owens
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-17 Thread Remco
Shouldn't the Telepathy framework be considered for storing account settings?

Remco
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-17 Thread Felix Kaser

Nice thoughts, really nice thoughts!

But I have to defend cheese! You're right, storing the pictures in a 
hidden directory is not that good! The maintainer of cheese, daniel 
siegel implemented it this way, because he thought storing all these 
random-crazy-looking-pictures taken with cheese in the photo directory 
makes more than a mess!


Anyway, we have changed that already in the latest version (which will 
be released with gnome 2.24 on Sept. 24)! Now the pictures and videos 
are stored either in a user-defined path (at the moment its only a gconf 
option, but it could be part of a preferences dialog too in future...) 
or in the standard xdg folder [1], for example /home/foo/Videos/Webcam 
(if the gconf option is not set)!


So, try out the new cheese and tell us if you like it ;)

Best Regards, Felix Kaser

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

Martin Owens schrieb:

Dear Ubuntu and Evolution Developers,

I'm sending this email to the gnome evolution hackers list to see what
their thoughts are.
  
I have noticed a really odd disconnect in gnu/linux with user data

which has me a little worried. Some user data is hidden from users in
configuration directories.

Technically configuration directories denoted by being hidden
(suffexed with a '.') are there to hold collections of configuration
files for the applications which they serve. But there are plenty of
programs using these directories to store the data results as well as
configuration.

For consideration I present Cheese, a very nice tool for using
web-cams to take photos with weird disfiguring effects. The problem as
I see it is that Cheese stores each of the photos in it's ~/.cheese
directory which makes them hidden from the user. Instead I propose
that Cheese use a standard directory (possibly configurable) such as
~/Photographs/Cheese or ~/Documents/Cheese which is accessible to user
browsing.

Cheese is an excellent example of making user data more accessible to
casual file browsing which is not just limited to jpeg images but
could just as easily apply to the way Evolution stores emails,
addresses, contacts and so on. In these instances the data is always
bound up in evolution specific formats inaccessible to casual browsing
as well as casual integration (without delving into the EDS API)

I'd like data to be available to send in an email, or browse in
nautilus (or on a command line) I'd like to be able to open the same
jpeg in image viewer and gimp, not just in what ever created or
generated them. I'd like to be able to open addresses and copy an
event file to my thumb drive. Wouldn't it be good to backup all your
files without configs and be sure your not missing emails or
bookmarks?

In fact the methods we use to store data seems to be along the same
lines that certain Windows and Mac programs use to obfuscate and hide
data in order to lock users into their products. Do we really need to
do this on our gnu/linux systems? Should we instead intend user data
to be converted with plugins and export features in every application
because of their hidden default outputs?

This issue may be interesting to the FDO (freedesktop.org) crowd. It
is a very heavy topic that will probably get me a little flaming
because it goes against what is currently best practice.

Best Regards, Martin Owens
___
Cheese-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/cheese-list

  


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-17 Thread Onno Benschop
On 13/09/08 11:48, Martin Owens wrote:
 Technically configuration directories denoted by being hidden
 (suffexed with a '.') are there to hold collections of configuration
 files for the applications which they serve. But there are plenty of
 programs using these directories to store the data results as well as
 configuration.
   
I think this idea is extremely valuable and merits robust discussion to
discover ways to encourage application developers to incorporate this
way of approaching data storage.

I wonder how would you differentiate between data and configuration if
you were to write a specification for this?

Consider for example Pidgin, which stores its account data within a
.purple directory. The same tree also contains logs for each of the
discussions, icons, application preferences and miscellaneous other files.

The account information is stored in an XML file which mixes
Pidgin-specific data with user IRC account data.

What I'm asking is, at which point do you think the line between
application data and user data needs to be drawn, or do you think that a
best practice approach might incorporate the idea that if your
application stores information that is useful to another application, it
should be stored in a non-configuration location?

-- 
Onno Benschop

Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA)
--
()/)/)()..ASCII for Onno..
|?..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -   [EMAIL PROTECTED]


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Configuration masquerading Data

2008-09-14 Thread Andre Klapper
Am Freitag, den 12.09.2008, 23:48 -0400 schrieb Martin Owens:
 For consideration I present Cheese, a very nice tool for using
 web-cams to take photos with weird disfiguring effects. The problem as
 I see it is that Cheese stores each of the photos in it's ~/.cheese
 directory which makes them hidden from the user. Instead I propose
 that Cheese use a standard directory (possibly configurable) such as
 ~/Photographs/Cheese or ~/Documents/Cheese which is accessible to user
 browsing.

Just FYI, this has been fixed three months ago:
http://bugzilla.gnome.org/show_bug.cgi?id=509475

andre
-- 
 mailto:[EMAIL PROTECTED] | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers