[Evolution] XLIST Support?

[Adam Tauno Williams]

I've posted this question before [in 2009], but nobody replied then.
But it came up in conversation again today, so I figured I'd post it
again.

Is there any support for XLIST in Evolution?  There is basic XLIST
support to Cyrus IMAPd [the world's ultimate IMAP server].  This would
be yet another small step towards zero-config mail clients [this system
administrator's long... long running dream. :)]







signature.asc
Description: This is a digitally signed message part
___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3

[Brian A Anderson]

On Thu, 2012-08-09 at 08:47 -0430, Patrick O'Callaghan wrote:
> On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote:
> > Finally, I would just point out that the best way of maintaining email
> > for use on multiple systems and that is fairly impervious to changes
> > in version is to keep your mail on a server and access it using IMAP -
> > that way you don't have to worry about moving data and if the upgrade
> > procedure doesn't work, all you will ever have to do is to re-enter
> > the account configuration.
> 
> +1. In fact since Evo has supported IMAP since the beginning, a
> migration strategy for widely separated versions is to move the old mail
> onto an IMAP server, switch Evo versions, then just access it with the
> new one (or download it again if you really must). Pity this isn't so
> easy for contacts, tasks, filters etc.
> 
> poc
> 

Again this is not a practical way for me to have solved my problem.
I was forced into the situation by having a dying machine.
I believed I had minimal time once my system started to fail until it
was gone.   

In the long run an IMAP server is not really a good solution for I have
a less than perfect/good ISP.  I still need to access mail that arrived
both distant past and recent past.  Neither happen if either ISP net or
ISP's imap server go down.  Obviously, I am not using my Linux system in
an office building with a real IT team.   

Perhaps if I had 25 years ago had started with a system like IMAP, I
would not have gotten used to using a mail system that loads mail
messages into my local space.   Isn't hind sight perfect.

Another feature that IMAP presents could be support of multiple systems.
And again I don't have a real multiple systems usage.  I have 2 laptops
one old, one new.  Old one is dying. IE I am headed to having one
laptop.

Also I am using Evolution for mail use only and don't really care about
calender, contacts etc.

> ___
> evolution-list mailing list
> evolution-list@gnome.org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-list


___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3

[Brian A Anderson]

On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote:
> > Why should the backup not maintain a canonical form of all the aspects
> > of a mail system vs backing up on the way in which the data is stored.
> > A canonical form would have forced all versions to be able to backup and
> > restore with full backwards and forwards compatibility.
> > The canonical form could evolve with versioning of data forms as they
> > get more complex and programs evolve.
> 
> Sorry, I didn't really address the underlying aspect of what you are
> saying here.
> 
> In the dim and distant past email was held in standardised data stores -
> i.e. mbox files.  It was an almost universal standard and no matter what
> program you used, it could be read and modified and other programs would
> still be able to work with it.  And Evolution used that standard.  To
> all intents and purposes, that was the canonical form.  Then some kind
> person invented MIME and the size of email messages expanded
> exponentially and all of a sudden the forever canonical form was not
> good enough - the files became too big, too unwieldy, too slow and
> things had to change.
> 
> Similarly with configuration data - in the early days of Unix and a
> single INBOX on your local system, there was no configuration necessary
> - then POP, then IMAP, then Exchange all came along and something,
> somewhere had to remember what the program was supposed to do.  There
> was no standard for such info so every program did its own thing.  Evo
> did have a canonical form of the data, it was in flat files in the
> Evolution private folders, but that eventually became too slow and too
> fragile, so they changed to using gconf - which is now being deprecated
> in favour of dconf.
> 
> What I'm trying to say is that 20:20 hindsight is a wonderful thing -
> but it is incredibly difficult to design a data storage format that is
> totally impervious to future changes and is efficient enough for
> everyday usage.  I'm also fairly certain that if there was a standard
> for holding or exchanging account information and data between different
> programs, then Evo would have embraced it.
> 

What you said about mbox is not about canonical form. It is a standard
way of storing mail info.  The proper/canonical way of doing a backup is
to read each canonical item from whatever store mechanism you use and to
stores it canonically for restoration.   The restoration process is the
reverse it takes canonical items from a canonically organized store and
places that data  into whatever storage mechanism is used in this
application.Thus each version, more importantly each version that
has a different mbox, maildir etc method of storing info would have a
different backup and restoration set of routines.

Evolution does NOT use a canonical backup.  It uses a trivial file
backup using tar.  At least for the 2.24.5 version that I was worried
about getting files from.

The Maildir mechanism used currently is not canonical either it is yet
another "standard" way of storing the mail data.


> Finally, I would just point out that the best way of maintaining email
> for use on multiple systems and that is fairly impervious to changes in
> version is to keep your mail on a server and access it using IMAP - that
> way you don't have to worry about moving data and if the upgrade
> procedure doesn't work, all you will ever have to do is to re-enter the
> account configuration.

Hindsight is perfect isn't it.
I was never really interested in a multiple system environment.  It was
forced upon me as I was forced to retire a sick and dying machine and
replace it with another machine.  I do not live in a network hub.  MY
network here is not as reliable as I would like.  Nor is my ISPs mail
server. Therefore I must be able to see messages that I have received on
my machine even if I don't have networking available.

While some models for what a user of a computer or a computer program
are may make all users homogenous,  I assure you that we are not
identical in any way shape nor form.  We all have our own needs and
methods of work.   You may like some and dislike others.  But we all use
tools differently.   In a true office environment at a workplace the IT
department can force procedure.  I am not in that environ, I must choose
by own based upon my experience and lack of interest in  version
chasing.


What made my situation in this scenario weird by how some would view the
use of different versions of evolution is that I had data that I finally
got via backup off of the dying machine.   But before the dying machine
actually dies I got the new machine up and running and started using it
versus being cut off and not having any mail service at all. Or
conversely living on a dying machine while I figrured out how to do a
multiple version migration. Thus I wandered helplessly into a merge of
data from my old system into data that is/was currently arriving.

The process I used was to attempt to perform a back

Re: [Evolution] Problem with Inbox indexing.

[George Reeke]

On Wed, 2012-08-08 at 18:03 -0500, Aaron Konstam wrote:
> On Wed, 2012-08-08 at 17:28 -0430, Patrick O'Callaghan wrote:
> > On Wed, 2012-08-08 at 16:10 -0500, Aaron Konstam wrote:
> > > I am using evolution 3.4.3 and periodically I have the problem that the
> > > indexing on Inbox gets stuck. That is when I delete a message the
> > > counter associated with Inbox does not change.

With Evo 2.12.3 (please, I know it's old, it's what RedHat gives me),
I see this problem all the time.  I found that if I just click on a
different mail box, then click back on the one that's stuck, it
corrects itself.  Maybe worth a try w/newer version since it's so easy.
George Reeke

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3

[Patrick O'Callaghan]

On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote:
> Finally, I would just point out that the best way of maintaining email
> for use on multiple systems and that is fairly impervious to changes
> in version is to keep your mail on a server and access it using IMAP -
> that way you don't have to worry about moving data and if the upgrade
> procedure doesn't work, all you will ever have to do is to re-enter
> the account configuration.

+1. In fact since Evo has supported IMAP since the beginning, a
migration strategy for widely separated versions is to move the old mail
onto an IMAP server, switch Evo versions, then just access it with the
new one (or download it again if you really must). Pity this isn't so
easy for contacts, tasks, filters etc.

poc

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3

[Pete Biggs]

> Why should the backup not maintain a canonical form of all the aspects
> of a mail system vs backing up on the way in which the data is stored.
> A canonical form would have forced all versions to be able to backup and
> restore with full backwards and forwards compatibility.
> The canonical form could evolve with versioning of data forms as they
> get more complex and programs evolve.

Sorry, I didn't really address the underlying aspect of what you are
saying here.

In the dim and distant past email was held in standardised data stores -
i.e. mbox files.  It was an almost universal standard and no matter what
program you used, it could be read and modified and other programs would
still be able to work with it.  And Evolution used that standard.  To
all intents and purposes, that was the canonical form.  Then some kind
person invented MIME and the size of email messages expanded
exponentially and all of a sudden the forever canonical form was not
good enough - the files became too big, too unwieldy, too slow and
things had to change.

Similarly with configuration data - in the early days of Unix and a
single INBOX on your local system, there was no configuration necessary
- then POP, then IMAP, then Exchange all came along and something,
somewhere had to remember what the program was supposed to do.  There
was no standard for such info so every program did its own thing.  Evo
did have a canonical form of the data, it was in flat files in the
Evolution private folders, but that eventually became too slow and too
fragile, so they changed to using gconf - which is now being deprecated
in favour of dconf.

What I'm trying to say is that 20:20 hindsight is a wonderful thing -
but it is incredibly difficult to design a data storage format that is
totally impervious to future changes and is efficient enough for
everyday usage.  I'm also fairly certain that if there was a standard
for holding or exchanging account information and data between different
programs, then Evo would have embraced it.

Finally, I would just point out that the best way of maintaining email
for use on multiple systems and that is fairly impervious to changes in
version is to keep your mail on a server and access it using IMAP - that
way you don't have to worry about moving data and if the upgrade
procedure doesn't work, all you will ever have to do is to re-enter the
account configuration.

P.



___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3

[Pete Biggs]

> 
> Again my situation was a bit different as I said in my first paragraph.
> I was really doing a merge more than a restoration.
> So some of the suggestions were never going to "really" work completely.

And you were doing a merge because you started using Evolution before
letting Evolution see your original data - that's really what I was
getting at.  Yes, the upgrade procedure from very old versions of the
backup file is less than optimal, but I don't think that is sufficient
grounds to say that Evo "abandoned those with older systems", especially
when you didn't really give it a chance to update in-situ files.

> Now look at evolutions data store.
> Each canonical message under 2.24.5 and 3.4.3 are stored differently.
> Yet they arrived into their versions of evolution using the same
> mechanisms.   
> Why should the backup not maintain a canonical form of all the aspects
> of a mail system vs backing up on the way in which the data is stored.
> A canonical form would have forced all versions to be able to backup and
> restore with full backwards and forwards compatibility.

Yes, the backup/restore process is fairly naive - it is basically dump
the config data from gconf (or dconf) and then tar it up with the data
files - the restore process is the reverse, untar the data and dumped
configuration, then merge the config into gconf.  The problem with using
such an old backup file is that the format of all the components
(configuration and data store) has changed, as well as the location of
those files.  It was never meant to be used when upgrading systems, it
was meant to be used to backup and restore data to the same version.

> The canonical form could evolve with versioning of data forms as they
> get more complex and programs evolve.

Yes, that would be a good ideal - I'm sure the developers would welcome
any help you can give them in re-writing the backup and upgrade code.
The issue really is how much effort should be put in to dealing with
something that is relatively rarely used - the developers team is small
and they are hard pressed.  If you think this is an area where Evolution
needs to be improved though, then file a bug on it, and if it is given
sufficient support, then no doubt it will be looked in to.

> So How many users really want to be slaves to version creeping and
> version hopping?

Users don't - that's why I put them on systems that don't have short
lifetimes.

> > 
> > The user certainly doesn't need to rush to update; too many LINUX users
> > are addicted to the next-greatest-patch which is an attitude that
> > seriously impedes real world productivity [hey, let me update first
> > thing Monday morning and break my desktop!].  'Immediate update' also
> > provides no pragmatic upside [let's be honest - *most* security fixes
> > are pretty obscure and only effect boxes using particular
> > applications/services in a particular configuration].
> 
> Name me two security fixes to Linux that fixed publically seen and
> experienced problems.  Not just those that some security geek says are
> important and are possible.  But happened.

Metasploit (a framework for "ethical" intrusion and penetration testing)
has over 650 usable, live remote exploits for Linux.  There are then a
whole load of privilege escalation exploits to gain root.  Not all the
exploits work, mainly because systems have been updated and patched so
they don't work.  But they do work on systems that aren't patched.

Before I took control of all the Linux boxes where I work, I was having
to deal with intrusions about once a week - virtually all of them on
unpatched systems; now I enforce updates and have locked the machines
down, I get virtually no intrusions.

These are real world, real intrusions, real data loss, that happened.

> > 
> > I apply updates once a month; and I typically upgrade my distro a full
> > month after a release [plus a month worth of updates].  This has
> > provided me with a very smooth ride.  I try to recommend this policy,
> > but immediately after I say this most users are subscribing to a factory
> > repository and doing a "zypper up"... sigh. :)
> > 
> I am glad that you have had a good luck with a monthly update.
> I have in several years attempted only two updates.
> AND BOTH FAILED TO COMPLETE!

Updates or upgrades?  I have about 200 Linux systems, they automatically
update from repositories (strictly controlled repositories!) and I've
never had an update that left a system in an unusable state.

Upgrades are different matter.  You can't do major version upgrades on
RHEL/CentOS systems, it is always a wipe and re-install.

> 
> > > In that case, with all due respect, why are you using Fedora! If you want
> > > stability, then use a RHEL clone such as CentOS or ScientificLinux -
> > > they will guarantee support for about 5 years after EoL of a particular
> > > version - but you still have to install updates.
> > 
> > Agree. If long-term is what the user is looking for then Fedora is a
> 

Re: [Evolution] "Mark messages as read" option will return in 3.6

[v.spagnolo]

On Wed, 2012-08-08 at 10:29 -0400, Matthew Barnes wrote:
> Haven't heard a peep about the other removed options, but I was taken
> aback at the backlash and confusion over the "Mark messages as read"
> removal on this list, our IRC channel, and various support forums.
I recall learning a bit about design in that conversation. Thanks for
that. 

> Clearly I underestimated its popularity/usefulness, so it will return in
> Evolution 3.6.  No more having to memorize dconf keys.
Thank you.

V


___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list