Subj : fido in sync with multiple devices
To : mark lewis
From : August Abolins
Date : Sun Apr 07 2019 10:42 pm
On 07/04/2019 2:02 p.m., mark lewis : August Abolins wrote:
> you forget about the lastread pointers... news clients keep up with the
> lastread pointers themselves... not the BBS or news server...
Ya.. the lastread pointer issue! For now, the volume of mail (in fidonet) is
not too much of a bother to keep up with or see previously read messages. But
I can certainly appreciate the matter.
I found the following discussion about this problem:
-= 8< =-
Before the update to feedly 16 everything was perfectly in sync: When I read
everything new in Firefox I could open feedly on my Android device and got the
"you read everything ..." message - perfect! When there were new feeds and I
read them on Android I did not get them as unread on Firefox later.
However, since the update to feedly 16 this changed. Now stuff I read in
Firefox does not show up as already-read on Android and vice versa. That's
super annoying and actually this kind of syncing is the reason I started using
feedly in the first place - when reading feeds at home, at work and from mobile
it's very important to keep read items in sync. Especially with high-volume
feeds such as 9gag.
1,846 votes
ThiefMaster shared this idea · Jun 17, 2013
-= 8< =-
Since 2013, it looks like the "problem" at feedly has been solved.
> so you have to manually sync the lastread pointers on each device...
How do you do the manual syncing with Thunderbird nntp areas? Auto-syncing
works with email/IMAP across clients, but the only thing marked "sync" for nntp
is "Download" messages. :( ..and that ain't gonna help when I want to resume
reading with another client for the account/server.
> AA> [1] save a reply-in-progress at one device, and resume with it at
> AA> another device before actually sending it off.
>
> you can get this if the BBS offers the ability to save drafts... at
> least one BBS that i know of does this now if the connection is lost
> while writing a message... it only offers one draft, though, and you
> have to continue it immediately when you reconnect...
I remember seeing that at a few BBSes, in the past.
Worked great over the tender dialup.
I wonder if this might work:
Client #1 (laptop)
- connect to server
- fetch new messages
- disconnect
- read, create replies or save drafts for later resume
- reconnect to server, BUT, only send sync:data "update LOCALLY READ markers
and draft status" on messages in progress.
- disconnect.
Client #2 (tablet)
- connect to server
- request "sync:data" from session with #1 above.
- fetch messages from where you left off from #1 above, BUT INCLUDE any UNREAD
messages that have not been confirmed with sync:data above (this is the key,
unlike QWK, for example).
- disconnect
- resume read/write.
- reconnect, send sync:data
- disconnect
Client #1 (laptop)
- connect to server
- request "sync:data" from session with #2 above.
- fetch messages from where you left off from #2 above.
- disconnect
...and so on.
.../|ug
--- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.
* Origin: - nntp://rbb.fidonet.fi - Lake Ylo - Finland - (2:221/360)
