Subj : Re: NET 1 tidy-up
To   : Oli
From : Avon
Date : Fri Sep 23 2022 03:18 pm

On 22 Sep 2022 at 09:24a, Oli pondered and said...
 
 Ol> My question was more about the copying and distribution of the old
 Ol> mails. Do you want to copy the messages as they are to the new echo and
 Ol> then export the old mail from the new echo to every downlink? Will
 Ol> MSGIDs and dates stay the same? I would expect some tossers / nodes
 Ol> would sort the mails to the DUPES or BAD area. Or do you want to forward
 Ol> the messages with a new header to the new echo, which would break
 Ol> threading. Or is there some magic tool or other way of merging echos
 Ol> that would avoid the problems? I'm curious if merging of old messages
 Ol> into a new echo is possible without creating a mess.

Well my thinking is to do the latter, so forwarding the messages posted in a echo (to be removed) to the new echo, and doing so in the order the original messages were posted in.

Testing things last night I can see how I can forward a message into a new echo and in doing so a new MSGID is created. So messages in the new echo shouldn't (hopefully) be picked up as dupes from the old echo. 

Yes, the threading of old messages that are forwarded would break but in forwarding them in sequence I think the overall meaning of who said what and when should not be lost on anyone stepping through the messages in sequence. Of course, any further replies to those messages would pick up their new MSGIDs and the opportunities for threaded conversations would resume.

 Ol> Anyway, I don't grant permissions to copy/merge _my_ mails from old to
 Ol> new echos. Quoting and cross-quoting is fine, but I expect that my
 Ol> original mail is distributed unmodified, which includes the AREA: line
 Ol> and the context they are appearing in.
  
Sigh. What is your concern? If the full discourse is being carried over between echos and the contents of your posts are not being modified other than the fact that they are now in a new echo that supports carries the very subjects the threads you feature in, I fail to see the issue.

 Ol> My proposal: create new echos (if you really have to) and retire the old
 Ol> ones slowly. First read/write with weekly reminders, then read-only.
 Ol> When everyone had a chance to pickup the new echos, then the old ones
 Ol> can be purged from the Hubs / Areafix. BBSing is slow.

Well thanks for your proposal but I don't feel the BBSing needs to be 'slow' nor does the pace of changing echomail setup for the network has to be a incrementally measured as you suggest.

Conversations about the more recently introduced echomail areas have been happening here for nine months now... I can't be accused of rushing things :)

Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going'
avon[at]bbs.nz | bbs.nz | fsxnet.nz 

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.