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] Removing libical fork, moving to new upstream?

2008-09-23 Thread IGnatius T Foobar


I have applied Chenthill's memory management patches (only to the 
'libical' directory and to the examples -- still have to do the 
'libicalcap' and 'libicalss' directories) using function names ending in 
_r.  

IMHO, HANDLE_LIBICAL_MEMORY can be removed.
  


Ok folks, it's done ...

The remaining portions of libical (libicalcap and libicalss) have been 
converted to the _r API.   (The test suite still uses the old API and 
will continue to do so for a while.)


Now is the time for Evolution code to be updated to use the new calling 
syntax.


Is there anything we can do to facilitate this, or should we just hang 
out and wait for you folks to kick the tires on the new library?  Let me 
know...


  -- Art

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


Re: [Evolution-hackers] Evolution: Taking forward...

2008-09-23 Thread Gediminas Paulauskas
I remember sending an Evolution copyright assignment to Ximian. Just
in case you also need my permission, but could not reach me via old
email [EMAIL PROTECTED]:

I agree to the re-licensing of any Evolution code I have written.

Would be nice if you changed the email, or, if you are not aware of
any code left, just remove me from contributors.
___
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


[Evolution-hackers] Instant Messaging information on Evolution Contacts

2008-09-23 Thread Fabio Rafael da Rosa
I'm implementing synchronization with google contacts for instant
messaging information on conduit. While implementing, i noticed that
evolution does not have entries for some IM's like google talk and
skype. First I thought on implementing some kind of transalation(for
google talk is easier, because it's jabber anyway... ), but, for things
like skype, for example, it's a problem, so now I think it's better if a
try to create it on evolution(create a patch for evo).
But, I would like to hear from an evo developer what's better in this
case. 

Thanks in advance
-- 
Regards
Fabio Rafael da Rosa 
[EMAIL PROTECTED]




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


[Evolution-hackers] EDS architecture

2008-09-23 Thread Tomasz Melcer
Hello,

I am interested in using EDS in my own projects. I looked for any docs
that would be useful to learn EDS architecture, but only found API
reference, which is not so helpful. I'd like to build a big picture of
how EDS works. Can anybody point me to proper document?

I also have two more specific questions. Firstly, is there any kind of
software that can be used to synchronize data from EDS using opensync
framework, without actually using Evolution? I'd like to use it in an
embedded environment (OpenMoko Freerunner). I know that there is 'sync'
from pimlico-project, but the webpage says it is in a very early state.

Secondly, I'd like to add to EDS content my own fields. Looking at the
API reference I see functions to get list of allowed fields (like
e_book_get_supported_fields), but I guess the server has to implement
them to be working properly? I'd like to add things like XMPP ID or
private notes to contacts, or GPS location or adding more detailed
categories for events.

Thanks in advance,
Tomasz Melcer

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


Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory

2008-09-23 Thread Michael Meeks

On Sat, 2008-09-20 at 00:47 -0500, Hans Petter Jansson wrote:
 Wouldn't it be possible to use a different directory, e.g.
 mail/local-index/folders.db? That would avoid both problems.

That seems like a great idea to me; at least - if the 'hot' data set of
evolution is normally just the summary information, then keeping that in
a single directory [ ie. mangle the path names into file names ] would
make it rather more likely to be contiguous on disk too which might be
nice:

~/.evolution/mail/summaries/local-Inbox-suse-kernel.db # etc. ;-)

 I still think relocating folders.db is a better option, since it would
 work for everyone without necessitating an upgrade.

Sounds best to me, if we can do it that is.

Regards,

Michael.

-- 
 [EMAIL PROTECTED]  , Pseudo Engineer, itinerant idiot


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


Re: [Evolution-hackers] Instant Messaging information on Evolution Contacts

2008-09-23 Thread Andre Klapper
Am Freitag, den 19.09.2008, 17:48 -0300 schrieb Fabio Rafael da Rosa:
 I'm implementing synchronization with google contacts for instant
 messaging information on conduit. While implementing, i noticed that
 evolution does not have entries for some IM's like google talk and
 skype. First I thought on implementing some kind of transalation(for
 google talk is easier, because it's jabber anyway... ), but, for things
 like skype, for example, it's a problem, so now I think it's better if a
 try to create it on evolution(create a patch for evo).
 But, I would like to hear from an evo developer what's better in this
 case. 

I'm not a developer, but with regard to any *potential* API changes or
code additions, feel free to also consider improving integration of
Evolution with the telepathy/empathy framework that we now have in GNOME
2.24.

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


Re: [Evolution-hackers] Evolution: Taking forward...

2008-09-23 Thread Rob Bradford
On Fri, 2008-07-11 at 04:21 -0600, Srinivasa Ragavan wrote:
 Hello guys,

 It would be really helpful if you can post a public/explicit mail with
 permissions to do it, or code pointers - if you think you wrote a
 piece of Evolution code  object.

Permission granted for any pieces i've personally produced (those with a
ChangeLog email address of [EMAIL PROTECTED])

Regards,

Rob

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


Re: [Evolution-hackers] EDS architecture

2008-09-23 Thread Patrick Ohly
On Sat, 2008-09-20 at 21:34 +, Tomasz Melcer wrote:
 I am interested in using EDS in my own projects. I looked for any docs
 that would be useful to learn EDS architecture, but only found API
 reference, which is not so helpful. I'd like to build a big picture of
 how EDS works. Can anybody point me to proper document?

I'm not aware of any.

 I also have two more specific questions. Firstly, is there any kind of
 software that can be used to synchronize data from EDS using opensync
 framework, without actually using Evolution?

OpenSync should have support for synchronizing EDS. The last time I look
at it (three years ago) it wasn't particular stable, so I wrote a
stand-alone SyncML client for Evolution/EDS (SyncEvolution). Depending
on what you want to do one or the other might be more suitable.

 Secondly, I'd like to add to EDS content my own fields. Looking at the
 API reference I see functions to get list of allowed fields (like
 e_book_get_supported_fields), but I guess the server has to implement
 them to be working properly?

vCard and iCalendar are stored verbatim when using the normal, file
based EDS backend. You can therefore store arbitrary extensions.

-- 
Bye, Patrick Ohly
--  
[EMAIL PROTECTED]
http://www.estamos.de/

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