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)

.