| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Re: Message Pointers on n |
On 09/07/14, Psi-Jack said the following... Ps> One more quirk I can suggest to iron out. Ps> Ps> When a user posts a new message, and their message read pointer for that Ps> message base is already at the last message before their own new post, it Ps> would be very nice if Mystic would automatically adjust the message Ps> pointer to mark the user's own new post as read, because, they literally Ps> just wrote it, but newscan shows it. i'm between the options on this... on the one hand, it kinda makes sense but what happens if new messages have been tossed into the message area while the user was writing their message? this is why JAM (not sure about SQUish at the moment) has two read pointers... with only one pointer (lastread), the user could miss messages if it was set to be equal to the post they just made... with two pointers, lastread and highread, then maybe setting highread to their post might be OK but i err on the other side and say not, not really... just because they wrote it doesn't mean that they have read up to that point... the deal with two pointers is that while reading messages, one might jump up to the next post in a thread (mystic doesn't yet support this) and then return to where they were to continue reading... their highread would point to the highest message number they have read but the lastread pointer shows where they are in the list of posts... i might read a message and then jump on up to the next reply to that post without reading the other in between... when i'm done, i can return to the post where i jumped from and go on from there... if i drop my connection after the jump and before i return back, then yes, the lastread and highread would both point to the same message and i would "loose" those i skipped unless i specifically went back hunting for them... Ps> I don't know, that's just my own thought. I think opinions on others on Ps> this might be good to get to see if they feel the same. when (if?) the JAM (and SQUish) capabilities are fully implemented, things should be clearer and easier to follow... disclaimer: it has been over a decade since i used and tested SQUish bases... the main software i run was the ones that created JAM bases so i'm much more familiar with them at this point in time but there's still some aspects of them that i've forgotten... --- Mystic BBS v1.10 A51 (Windows) þ Synchronet þ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)* Origin: (46:1/132) SEEN-BY: 19/33 103/705 124/5013 5014 5015 5016 130/803 154/10 203/0 221/0 SEEN-BY: 229/275 426 261/38 280/464 5003 292/624 396/40 45 423/120 633/267 280 SEEN-BY: 640/1384 712/132 620 848 770/1 31999/99 @PATH: 124/5013 5014 396/45 280/464 712/848 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.