mjwestkamper at weiinc.com
Wed Apr 17 19:42:54 UTC 2019
Please see below...
On 4/17/2019 2:01 PM, Mark Banner wrote:
> On 16/04/2019 19:52, MJWestkamper wrote:
>> One example; many users use a laptop for their e-mail client.
>> Generally they have somewhat limited disk space and many use a SSD.
>> E-mail chains can get very lengthy and may include graphics and
>> attachments. The e-mail database can get very large very quickly.
> For some people, I suspect this might be true, but I doubt it is an
> issue on a large scale. If you have a basis for this being a wider
> issue, please let everyone know.
I can offer from a personal experience that the issue is significant. At
my firm we've built a kluge to provide the means to archive e-mail on a
server and setup a different instance of Thunderbird to access the
archive. It is at best clumsy. We must archive for the historical
record. I have counseled others on how to do the same. There was a
discussion some time ago on a Thunderbird forum, I can't find the
thread, where this was discussed at length.
>> My comment relates to the topic here when considering topology. Where
>> and how the data are stored should consider the ability to not only
>> backup at a different location but to provide a indexable archive, at
>> a different location.
> Personally, I don't think we should talk about Thunderbird providing
> backup options. Backup is something that's been long resolved for
> personal computers and servers and there's not really much point in
> Thunderbird re-inventing it (and spending lots of time on it).
In part I agree. There are a lot of backup methods and there is no need
to create another, unless it does something useful. I look at e-mail as
a data base. I can backup it up and restore it. If I backup using the OS
backup or something similar I restore the data to a point in time. If I
have a database and I want to restore something specific, I have to
restore the whole backup, access what I want or merge the backups. Gets
> We could, however, make it so that recovering individual emails stored
> by Thunderbird is easier. For example the work for switching the on
> disk format to file-per-email rather than file-per folder would help
> with being able to select to restore a single email from a backup.
Yes, a file per e-mail or file per folder is a method. The indexing
files and searching the metadata was popular for a time. Relying of the
OS mechanisms turns out to be problematic. Google had a desktop search
too. It relied on the OS file system. Didn't work well for e-mail. The
problem as I see it; e-mail has a different structure and the container
should be different. For instance an SQL database is not a good
repository for an unstructured record set. The way its done now in
Thunderbird is good. Backing up or archiving e-mail in a form
Thunderbird readily uses seems to make sense.
> Archiving is a potentially different case and what you're suggesting
> makes me think of the facility I think Outlook had to store its emails
> in a pst file on a network drive (But still be able to access them).
> Not sure if it still has that.
> Generally again, I'd probably revert to how much of a problem for
> people generally is this. Having worked at a couple of large
> organisations, I've not known either to have this sort of requirement,
> nor for people needing it. We know there are people who save a lot of
> email, but how common is it and does it make it worth solving compared
> to everything else that Thunderbird currently needs to be doing.
I can't argue your point; simply not enough information. I do believe it
would be a good thing to consider as the problem is increasing
geometrically in time. I do know it is a problem in some cases.
Intuitively seems like a large problem. We could test the validity with
Ant too I realize resources available to work on Thunderbird are finite
and the requests far exceed those resources.
My original comments were pointed to a discussion on topology. If there
is a need to change Thunderbird topology, doing so with the ability to
later develop a means to extend its capability to access multiple data
structures on different devices would make adding an archive doable
without significant restructuring.
MJ Westkamper | WEI Inc.| 379 Middlesex Turnpike | Old Saybrook CT.
06475 | (860) 388-3038
More information about the tb-planning