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 backup of the old system using the evolution backup command. That file was named in the attempt from the new version of evolution 3.4.3s restoration command. This restoration failed. This is the proof that the backup and restoration between the two version I used was incompatible (see next para). This was the process that made the most sense and was suggested/recommended by many on this list. Some have objected to my comment that the evolution of Evolution has left users of older version behind as being incorrect. It is a FACT that the backup/restoration between these versions is not compatible ! Therefore the statement is TRUE! What is debateable is whether a user should be version chasing or not. The key thing that I need as a user not a builder/developer is the identification of key releases of the product that are stable and have real value to me as a user. By the way this post is not meant strictly to Pete. It is more a generic response to several messages. > > 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 _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
