589
edits
Thunderbird:Pluggable Store Migration: Difference between revisions
Jump to navigation
Jump to search
Thunderbird:Pluggable Store Migration (view source)
Revision as of 18:07, 14 January 2011
, 14 January 2011no edit summary
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
What, if anything, should we do with .mozmsgs directories? I guess we don't want to copy them because we'd need to mark the headers in the .msf file in the new directory as being indexed. The maildir store is special because the indexers should be able to use the messages in the store directly, and not make a copy. We need a way for the os search indexers to know this. Perhaps a boolean attribute on the store. Will the indexer need to know how to get the file from the message id? More likely, we'll need to be able to go from the file name to the message id, in order to open search hits. Perhaps we can add a new interface for this, and if the pluggable store implements that interface, the indexer will use it. | What, if anything, should we do with .mozmsgs directories? I guess we don't want to copy them because we'd need to mark the headers in the .msf file in the new directory as being indexed. The maildir store is special because the indexers should be able to use the messages in the store directly, and not make a copy. We need a way for the os search indexers to know this. Perhaps a boolean attribute on the store. Will the indexer need to know how to get the file from the message id? More likely, we'll need to be able to go from the file name to the message id, in order to open search hits. Perhaps we can add a new interface for this, and if the pluggable store implements that interface, the indexer will use it. | ||
An even simpler route for local accounts would be to simply create a new account/server with the desired storage type, and move all the folders from the source server to the target server, and then tweak the source server to use the new server's directory and storage type. But we'd still have the issue of indexers doing the right thing. Since migrating storage is going to change message keys, we may need to re-index. I think we actually want to do a folder copy, both because we only allow copies across servers, and calling it a move is technically wrong because the folder uri won't change. Asuth has suggested sending a compact complete notification to gloda, which tells it the message keys have changed, which it can handle. | |||
What about offline stores? In theory, we could just let nature take its course and let autosync repopulate the offline store, but that harm bandwidth-limited folks. I think we want to do something slightly different. We don't want to create a folder per se, just an offline store. And we only want to stream messages that we have offline. I think we want to call nsIMsgFolder::GetOfflineStoreOutputStream() and stream the message to the offline store. So the algorithm for offline stores would probably look something like this, for each folder: | What about offline stores? In theory, we could just let nature take its course and let autosync repopulate the offline store, but that harm bandwidth-limited folks. I think we want to do something slightly different. We don't want to create a folder per se, just an offline store. And we only want to stream messages that we have offline. I think we want to call nsIMsgFolder::GetOfflineStoreOutputStream() and stream the message to the offline store. So the algorithm for offline stores would probably look something like this, for each folder: | ||