So I've got a user that's telling me that there's no message read pointers being synced correctly with what he's read via the web interface as opposed to when he's scrolling through them now via text.
I'm not sure, it's been awhile, but it sounds familiar, and that may've been an issue close to, if not the primary, that I had stopped offering web based service at one point, too.
Is this known/handled at all?

---
þ Synchronet þ Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Khelair to All on Mon Nov 17 2014 03:56 am

So I've got a user that's telling me that there's no message read
pointers being synced correctly with what he's read via the web interface
as opposed to when he's scrolling through them now via text.
I'm not sure, it's been awhile, but it sounds familiar, and that may've been an issue close to, if not the primary, that I had stopped offering web based service at one point, too.
Is this known/handled at all?

Yes, it's handled, but the user needs to logoff the terminal server session before the pointers will be updated in the web GUI. They can't be accessed at the same time and expect them to be in sync.

digital man

Synchronet "Real Fact" #60:
How to get Synchronet technical support: http://wiki.synchro.net/howto:support Norco, CA WX: 64.5øF, 17.0% humidity, 5 mph W wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Khelair to All on Mon Nov 17 2014 03:56:00

So I've got a user that's telling me that there's no message read pointers being synced correctly with what he's read via the web
interface as opposed to when he's scrolling through them now via text.
Is this known/handled at all?

I don't remember for sure, but I don't think that I ever made ecweb update pointers. I do remember pondering it and seeing various pros and cons.

I wouldn't personally want it to update my new-scan pointers, because the "flow" of how I read things on the web is different (less linear) than I prefer on the console side. I think there's a "last read" pointer which might be useful as a sort of bookmark as you come and go or switch between interfaces.

I'm not sure, it's been awhile, but it sounds familiar, and that may've been an issue close to, if not the primary, that I had stopped offering web based service at one point, too.

If you can let me know how you would like it to work, we can see if it's doable. Bear in mind that when browsing a sub in ecweb, the first thread in the list contains the newest message in the sub. Viewing that message & updating the new-scan pointer for that thread would essentially mark everything older as having been read. Unless there's some per-message read/unread flag that I don't know about but would be happy to hear of.

---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Digital Man to Khelair on Tue Nov 18 2014 20:27:43

Yes, it's handled, but the user needs to logoff the terminal server session before the pointers will be updated in the web GUI. They can't
be accessed at the same time and expect them to be in sync.

He accessed the message bases via web like a month or more before he logged on via the terminal server. :P The problem was opposite of what was described here, and they weren't on at the same time at all.

---
þ Synchronet þ Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: echicken to Khelair on Tue Nov 18 2014 23:26:21

I don't remember for sure, but I don't think that I ever made ecweb update pointers. I do remember pondering it and seeing various pros and cons.

Ah yes. I can understand better now; hadn't really thought about it in depth from a developer standpoint. I don't think that my friend had, either, despite his well paid years in software development. ;)

I wouldn't personally want it to update my new-scan pointers, because the "flow" of how I read things on the web is different (less linear) than I prefer on the console side. I think there's a "last read" pointer which might be useful as a sort of bookmark as you come and go or switch between interfaces.

Yeah... Let's see there's got to be something better here. If nothing else, maybe an optional toggle, with a setting saved in JSON, though that seems like a horrible kludge. :P

If you can let me know how you would like it to work, we can see if it's doable. Bear in mind that when browsing a sub in ecweb, the first thread in the list contains the newest message in the sub. Viewing that message & updating the new-scan pointer for that thread would essentially mark everything older as having been read. Unless there's some per-message read/unread flag that I don't know about but would be happy to hear of.

Okay, so you're trying to make sure that this is a module tied on to the core, without having any massive change to the BBS internals. I totally understand and agree with that.
I'm going to talk with my friend a bit; like I said, he's been doing dev a lot longer than I have. Once he gets done scoffing and pointing fingers and actually thinks about the extent of the issue I'm pretty sure that we can come up with something that might do it. The thing I mentioned that I was alluding to above was making a checkbox, as fugly as that may be, with a boolean toggle, letting the user decide whether or not they want the most recent message that they've read in whichever sub to be setting their last_read pointer. I'll get back to you soon as I can on whatever I brainstorm with him; in the meantime I'd love to hear what you think of that fugly kludge. :) Maybe you know of a better way than a JSON addition to save that option?
I only thought about the JSON kludge, actually, because I just recently realized that with my new shell I'm going to have to save an option set that has no other place (per-user) to go in order to maintain the continuity of the interface that I'm trying to develop. Maybe if there's something better you know about it'll save me that trouble, too. :P
Best wishes.

---
þ Synchronet þ Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Khelair to echicken on Wed Nov 19 2014 08:52:20

Yeah... Let's see there's got to be something better here. If nothing else, maybe an optional toggle, with a setting saved in JSON, though
that seems like a horrible kludge. :P

If each user is going to have a preference, it would need to be stored somewhere, and that's normal / not what I would call a kludge. If you mean using the JSON DB service for this purpose, then that would be an unnecessary complication.

Okay, so you're trying to make sure that this is a module tied on to the core, without having any massive change to the BBS internals. I totally understand and agree with that.

I don't mean to imply that it's a big complicated issue or would require a complicated fix. It'd be pretty simple to do, really. I just had several reasons for not doing it in the first place.

mentioned that I was alluding to above was making a checkbox, as fugly
as that may be, with a boolean toggle, letting the user decide whether
or not they want the most recent message that they've read in whichever sub to be setting their last_read pointer. I'll get back to you soon as

Sure, something like that is possible, and I would prefer it being an option than the standard/only behaviour.

better way than a JSON addition to save that option? I only thought

It would be simplest to just make a per-user config file to hold ecweb preferences (only created when they change away from the defaults.) That file could contain JSON or be an INI, or whatever else. I believe that the 'data/user/' directory is the typical place to put these things.

better way than a JSON addition to save that option? I only thought
about the JSON kludge, actually, because I just recently realized that

There's no need to get hung up on JSON. Really all we would need at this point is to capture a user's preference on this matter, then store it somewhere, somehow, in some format.

I'm going to talk with my friend a bit; like I said, he's been doing dev a lot longer than I have. Once he gets done scoffing and pointing
fingers and actually thinks about the extent of the issue I'm pretty

Oh, well if that's his attitude, I don't really feel like helping. He can fuck himself.

---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Khelair to Digital Man on Tue Nov 18 2014 11:34 pm

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Digital Man to Khelair on Tue Nov 18 2014 20:27:43

Yes, it's handled, but the user needs to logoff the terminal server session before the pointers will be updated in the web GUI. They can't be accessed at the same time and expect them to be in sync.

He accessed the message bases via web like a month or more before he logged on via the terminal server. :P The problem was opposite of what
was described here, and they weren't on at the same time at all.

Ah, I didn't notice "ecweb" in the subject. That, I don't know about.

digital man

Synchronet "Real Fact" #51:
Answers to Frequently Asked Questions: http://wiki.synchro.net/faq:index
Norco, CA WX: 58.4øF, 62.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: echicken to Khelair on Wed Nov 19 2014 16:18:07

If each user is going to have a preference, it would need to be stored somewhere, and that's normal / not what I would call a kludge. If you mean using the JSON DB service for this purpose, then that would be an unnecessary complication.

Oh, alrighty. I haven't really done anything with much more than recreating a messaging interface and new interface to the telegram system so far, so I haven't really looked into things. I thought JSON would be the primary option available, and as such I was kind of dreading it. It's good to hear that this isn't the only option to work with.

I don't mean to imply that it's a big complicated issue or would require a complicated fix. It'd be pretty simple to do, really. I just had several reasons for not doing it in the first place.

For sure. Now that I've thought about it from the aspects of looking into the user & message base object structures, I totally get it.

Sure, something like that is possible, and I would prefer it being an option than the standard/only behaviour.

That's what I was thinking, too. Certainly wouldn't want to be default. Might be a good cause to open up development on a user preferences page, too, provided one doesn't exist. Goddamn, I'm sorry, I'm like waving my ignorance and lack of time to work on this lately in faces. I'll open up a goddamned page to the interface myself before I reply again here.

It would be simplest to just make a per-user config file to hold ecweb preferences (only created when they change away from the defaults.) That file could contain JSON or be an INI, or whatever else. I believe that the 'data/user/' directory is the typical place to put these things.

Awesome. I'm glad that it's not going to take some nasty sort of restructuring of the user objects or anything of the sort. What I was already discussing with my friend when I was telling him the original reasons for this not being a default behavior was some sort of 'blob' in the user record that could be utilized for whatever extensible information, but this is a great alternative.

There's no need to get hung up on JSON. Really all we would need at this point is to capture a user's preference on this matter, then store it somewhere, somehow, in some format.

Yeah I'll look into what's hanging out in that directory in just a bit here.

Oh, well if that's his attitude, I don't really feel like helping. He can fuck himself.

Alright let me backtrack just a bit here. *grin* I was typing that in such a manner for a couple of reasons... He's burnt out on software development and he's much more a QA guy, now, and he's excellent at troubleshooting design issues. I shouldn't have said scoffing and pointing fingers. Any of that that _did_ exist was immediately rectified when I mentioned the structure of the user & msgbase objects and records. He's really a great guy, or I wouldn't be bothering with such troubles for him, either. The other half of why I typed it in such a way is that I've got him actively logging in here again, finally, and I was kind of doing it hoping that he'd see it to 'rub his rhubarb' a bit and give him some shit.
He's really good at what he does, and he speaks developer a lot better than I do at this point. I hope you can blame that bit of misinformation on me, the middleman, and [hopefully] still entertain this idea with an open perspective.
Plus, like I said, it was a reason that I originally stopped using the interface in the first place... It really bothered me when I'd have to switch back and forth. It'd be nice to have at least a little something to hold place a bit... So it's not just him, or him & I, I'm guessing. Other people have to have run into this a bit.
Best wishes.

---
þ Synchronet þ Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Khelair to echicken on Thu Nov 20 2014 16:22:53

system so far, so I haven't really looked into things. I thought JSON
would be the primary option available, and as such I was kind of
dreading it. It's good to hear that this isn't the only option to work

JavaScript Object Notation (JSON) is fairly easy to work with, and nothing to be dreaded. In fact it's probably what I would end up using for this. Don't confuse JSON itself with the JSON DB, which would be overkill here. One can easily just save a JSON string to a file, then read it back later.

For sure. Now that I've thought about it from the aspects of looking into the user & message base object structures, I totally get it.

Well, it's not really about that. It's easy enough to update a user's message pointers. I don't have any technical concerns about this. It's just a user-experience consideration.

Look at it this way:

I'm browsing the "Forum" section of a BBS' ecWeb site. I open a board, then a sub-board that I like to read. I see a list of threads, sorted from those with the most recent messages in them, to those with the oldest. Ten new messages have been posted to this sub-board since the last time I looked at it. These messages are spread across three different threads. I click on the first thread, because it's the first one in the list. It contains three of the ten new messages in this sub that I haven't read. I scroll down to read the newest messages in this thread. My new-scan pointer is updated because I have viewed the newest message in this sub. As far as my pointers are concerned, I've seen all of the new messages in this sub (but I haven't really, just yet - there are seven others that I haven't seen, which won't be caught by my new scan the next time I SSH into the BBS.)

Of course this might be what people want or expect. I just don't think it's ideal. (Though neither is the way it currently ignores pointers altogether.) I can think of a bunch of ways to work with and around this, but they all involve compromises of one kind or another. This is why I shrugged and left things as they are for now.

What I could and probably should do, without complicating things unnecessarily, would be to add a visual indicator of which threads have unread messages in them. It would only be good until you browsed away from the current page, but would at least tell you where to look while you're there.

A previous version of ecWeb had a "new message scan" that was sort of okay. Maybe that could come back. I can't say that I really want to put any work into this right now. I've got other fish to fry.

Yeah I'll look into what's hanging out in that directory in just a bit
here.

Whatever you find there may or may not be informative in any way. It's really just a convenient place that's set aside for storing arbitrary per-user data files, as far as I know. (With the exception of the ptrs subdirectory there, but ignore it, because we'd only be operating on those files through abstraction.)

Alright let me backtrack just a bit here. *grin* I was typing that in such a manner for a couple of reasons... He's burnt out on software development and he's much more a QA guy, now, and he's excellent at troubleshooting design issues. I shouldn't have said scoffing and pointing fingers. Any of that that _did_ exist was immediately

Well, I do care about design and user-experience, which is why I didn't foist something on users that might lead to a confusing diddling of their pointers.

Scoffing and finger-pointing don't bother me too much. That's just a part of the "fun" of this shit. I'm just more tolerant of it when it's about some glaring inconvenience-causing or security-compromising error than when it's about a missing feature. If the suggestion has merit I'll likely implement it eventually, no matter how I heard about it.

That said, "eventually" could be a long time.

ecWeb is not without its multitude of flaws, and I can't say I'm particularly wild about it in general. It does however have a lot of features. If it's missing one and you suggest it, then sure, I'll look into it. If you scoff and point fingers because I didn't think of every possibility right off the bat, well ... fuck yourself, and I'll get to it when I get to it. That, sir, is just the manner in which I locomote.

it was a reason that I originally stopped using the interface in the
first place... It really bothered me when I'd have to switch back and forth. It'd be nice to have at least a little something to hold place a bit... So it's not just him, or him & I, I'm guessing. Other people
have to have run into this a bit. Best wishes.

It's entirely possible that you or other people have raised this issue with me and that I've forgotten about it. I don't however remember any big ecWeb-and-pointers discussions having taken place. If you do stop using something because it's lacking in some way, it never hurts to make a feature request. If you did and I ignored it, well ... heh, sorry. :|

Anyway, I'll see what I can do about this the next time I'm poking around in ecWeb's intestines and lower bowels. If you or your friend have a particular vision for how things would look or operate re: this, please let me know.

---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: echicken to Khelair on Fri Nov 21 2014 00:57:07

JavaScript Object Notation (JSON) is fairly easy to work with, and nothing to be dreaded. In fact it's probably what I would end up using for this. Don't confuse JSON itself with the JSON DB, which would be overkill here. One can easily just save a JSON string to a file, then read it back later.

I'm actually starting to learn quite a bit of it, in the coding that I've been doing. Haven't worked with dumping it to and from a string yet, but I assume there's a pair of methods that make it pretty simple.
The JSON DB is, indeed, where the confusion came from. That was the beast that I was dreading here. Thank you for pointing out the different terminologies to me.

Well, it's not really about that. It's easy enough to update a user's message pointers. I don't have any technical concerns about this. It's just a user-experience consideration.

Look at it this way:

this sub. As far as my pointers are concerned, I've seen all of the new messages in this sub (but I haven't really, just yet - there are seven others that I haven't seen, which won't be caught by my new scan the next time I SSH into the BBS.)

Yeah, totally got it. I have forgotten that the interface was threaded. I will transgress no further in this, however. I've got a tab open to the interface now.

Of course this might be what people want or expect. I just don't think it's ideal. (Though neither is the way it currently ignores pointers altogether.) I can think of a bunch of ways to work with and around this, but they all involve compromises of one kind or another. This is why I shrugged and left things as they are for now.

I've talked about the problem with my buddy. As I said, he's a dev, and he totally gets the problem now. I'm going to see if I can't find out what his preferences are, because when it comes to UI/UX, quite honestly, I suck. I'm good at text interfaces, and I'm good at coding internals, but I am terrible at knowing what a user (other than myself) wants. There's a chance I'll be able to bring him into the discussion here soon, we'll see if that happens or not.

What I could and probably should do, without complicating things unnecessarily, would be to add a visual indicator of which threads have unread messages in them. It would only be good until you browsed away from the current page, but would at least tell you where to look while you're there.

That'd definitely be a great improvement in general.

A previous version of ecWeb had a "new message scan" that was sort of okay. Maybe that could come back. I can't say that I really want to put any work into this right now. I've got other fish to fry.

I totally understand. Actually, I've been hampered in my career search lately because I haven't been working on any web apps, only console and system level stuff... Would you mind if I tinkered a bit myself?

Whatever you find there may or may not be informative in any way. It's really just a convenient place that's set aside for storing arbitrary per-user data files, as far as I know. (With the exception of the ptrs subdirectory there, but ignore it, because we'd only be operating on those files through abstraction.)

Gotcha.

Well, I do care about design and user-experience, which is why I didn't foist something on users that might lead to a confusing diddling of their pointers.

Yeah, that's a problem that's gonna take some thought. I'm starting to have a few ideas, though...

Scoffing and finger-pointing don't bother me too much. That's just a part of the "fun" of this shit. I'm just more tolerant of it when it's about some glaring inconvenience-causing or security-compromising error than when it's about a missing feature. If the suggestion has merit I'll likely implement it eventually, no matter how I heard about it.

:)

That said, "eventually" could be a long time.

Of course. This world has a way of making things that matter to us personally take quite the back seat to the things that we need to do to stay alive and afloat, that keep this giant machine destroying this wonderful planet that we live on.

ecWeb is not without its multitude of flaws, and I can't say I'm particularly wild about it in general. It does however have a lot of features. If it's missing one and you suggest it, then sure, I'll look into it. If you scoff and point fingers because I didn't think of every possibility right off the bat, well ... fuck yourself, and I'll get to it when I get to it. That, sir, is just the manner in which I locomote.

That is a sentiment I can understand and respect. :) Here's my take on ecweb: best alternative that I've seen so far. I like it, and when I've got the ability to have web service available, it's the one that I put up. Right now I just can't have any web servers open due to the restrictions on my network. When I said I stopped using it before, I didn't mean that I stopped offering the option; I've left it up, and multiple people used it while I still had it up. It was just a problem that I'd noted, so I stuck to text.

It's entirely possible that you or other people have raised this issue with me and that I've forgotten about it. I don't however remember any big ecWeb-and-pointers discussions having taken place. If you do stop using something because it's lacking in some way, it never hurts to make a feature request. If you did and I ignored it, well ... heh, sorry. :|

Not even sure I mentioned it before, actually. No worries.

Anyway, I'll see what I can do about this the next time I'm poking around in ecWeb's intestines and lower bowels. If you or your friend have a particular vision for how things would look or operate re: this, please let me know.

Wilco & thanks.

---
þ Synchronet þ Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Khelair to echicken on Sat Nov 22 2014 18:50:49

JavaScript Object Notation (JSON) is fairly easy to work with, and

I'm actually starting to learn quite a bit of it, in the coding that
I've been doing. Haven't worked with dumping it to and from a string
yet, but I assume there's a pair of methods that make it pretty simple.

Turning an object into a string (or a string into an object) is exactly what JSON is all about. You may have worked with objects in JS, and possibly object literals - which bear every resemblance to JSON.

The JSON DB is, indeed, where the confusion came from. That was the beast that I was dreading here. Thank you for pointing out the
different terminologies to me.

It's actually fairly easy to work with, but would add an extra set of steps to the configuration process, and more complexity than this problem merits. The JSON DB can be very useful, and it's worth keeping in mind for your future projects. If you're working on something that needs to store and read data from somewhere, depending on the context the JSON DB might be a good choice.

I totally understand. Actually, I've been hampered in my career search lately because I haven't been working on any web apps, only console and system level stuff... Would you mind if I tinkered a bit myself?

Well, go nuts. You've got a local copy. No skin off my nose if you mess around with it. If you come up with some improvements, let me know and I can see about integrating them.

That is a sentiment I can understand and respect. :) Here's my take on
ecweb: best alternative that I've seen so far. I like it, and when I've
got the ability to have web service available, it's the one that I put
up. Right now I just can't have any web servers open due to the

Thanks. I would probably do a lot of things differently now, but at least it is what it is: fairly easy to set up, easy to add content to, not so painful to customize, and a big change from the dated stock web interface.

didn't mean that I stopped offering the option; I've left it up, and
multiple people used it while I still had it up. It was just a problem
that I'd noted, so I stuck to text.

I stick to the terminal server myself, and rarely use ecWeb except to browse some subs on occasion that I don't normally scan. I'm not even sure why I worked on any of this web crap to begin with, considering I would rather do my BBSing in the traditional style.

---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com

Re: message read pointers betwixt ecweb & synchronetterminal iface
By: Khelair to Digital Man on Tue Nov 18 2014 11:34 pm

Re: message read pointers betwixt ecweb & synchronet terminal iface
By: Digital Man to Khelair on Tue Nov 18 2014 20:27:43

Yes, it's handled, but the user needs to logoff the terminal server session before the pointers will be updated in the web GUI. They can't be accessedat the same time and expect them to be in sync.

He accessed the message bases via web like a month or more before he
logged on via the terminal server. :P The problem was opposite of what
was described here, and they weren't on at the sametime at all.

Ah, I didn't notice "ecweb" in the subject. That, I don't know about.

digital man

Synchronet "Real Fact" #51:
Answers to Frequently Asked Questions: http://wiki.synchro.net/faq:index
Norco, CA WX: 58.4øF, 62.0% humidity, 0 mph ESE wind, 0.00 i

Re: message read pointers betwixt ecweb & synchronetterminal iface
By: Khelair to echicken on Thu Nov 20 2014 16:22:53

system so far, so I haven't really looked into things. I thought JSON
would be the primary option available, and as such I was kind of
dreading it. It's good to hearthat this isn't the only option to work

JavaScript Object Notation (JSON) is fairly easy to work with, and nothing to be dreaded. In fact it's probably what I would end up using for this. Don't confuse JSON itself with the JSON DB, which would be overkill here. One can easily just save a JSON string to a file, then read it back later.

For sure. Now that I've thought about it from the aspects of looking into the user & message base object structures, I totally get it.

Well, it's not reallyabout that. It's easy enough to update a user's message pointers. I don't have any technical concerns about this. It's just a user-experience consideration.

Look at it this way:

I'm browsing the "Forum" section of a BBS' ecWeb site. I open a board, then a sub-board that I like to read. I see a list of threads, sorted from those with the most recent messages in them, to those with the oldest. Ten new messages have been posted to this sub-board since the last time I looked at it. These messages are spread across three different threads. I click on the first thread, because it's the first one in the list. It contains three of the ten new messages in this sub that I haven't read. I scroll down to read the newest messages in this thread. My new-scan pointer is updated because I have viewed the newest message in this sub. As far as my pointers are concerned, I've seen all of the new messages in this sub (but I haven't really, just yet - there are seven others that I haven't seen, which won't be caughtby my new scan the next time I SSH into the BBS.)

Of course this might be what people want or expect. I just don't think it's ideal. (Though neither is the way it currently ignores pointers altogether.) I can think of a bunch of ways to work with and around this, but they all involve compromises of one kind or another. This is why I shrugged and left things as they are for now.

What I could and probably should do, without complicating things unnecessarily, would be to add a visual indicator of which threads have unread messages in them. It would only be good until you browsed away from the current page, but would at least tell you where to look while you're there.

A previous version of ecWeb had a "new message scan" that was sort of okay. Maybe that could come back. I can't say that I really want to put any work into this right now. I've got other fish to fry.

Yeah I'll look into what's hanging out in that directory in just a bit
here.

Whatever you find there may or may not be informative in any way. It's really just a convenient place that's set aside for storing arbitrary per-user data files, as far as I know. (With the exception of the ptrs subdirectory there, but ignore it, because we'd only be operating on those files through abstraction.)

Alright let me backtrack just a bit here. *grin* I was typing that in such a manner for a couple of reasons... He's burnt out on software development and he's much more a QA guy, now, and he's excellent at troubleshooting design issues. I shouldn't have said scoffing and pointing fingers. Any of that that _did_ exist was immediately

Well, I do care about design and user-experience, which is why I didn't foist something on users that might lead to a confusing diddling of their pointers.

Scoffing and finger-pointing don't bother me too much. That's just a part of the "fun" of this shit.I'm just more tolerant of it when it's about some glaring inconvenience-causing or security-compromising error than when it's about a missing feature. If the suggestion has merit I'll likely implement it eventually, no matter how I heard about it.

That said, "eventually" could be a long time.

ecWeb is not without its multitude of flaws, and I can't say I'm particularly wild about it in general. It does however have a lot of features. If it's missing one and you suggest it, then sure, I'll look into it. If you scoff and point fingers because I didn't think of every possibility right off the bat, well ... fuck yourself, and I'll get to it when I get to it. That, sir, is just the manner in which I locomote.

it was a reason that I originally stoppedusing the interface in the
first place... It really bothered me when I'd have to switch back and forth. It'd be nice to have at least a little something to hold place a bit... So it's not just him, or him & I, I'm guessing. Other people
have to have run into this a bit. Best wishes.

It's entirely possible that you or other people have raised this issue with me and that I've forgotten about it. I don't however remember any big ecWeb-and-pointers discussions having taken place. Ifyou do stop using something because it's lacking in some way, it never hurts to make a feature request. If you did and I ignored it, well ... heh, sorry. :|

Anyway, I'll see what I can do about this the next time I'm poking around in ecWeb's intestines and lower bowels. If you or your friend have a particular vision for how things would look or operate re: this, please let me know.

--

Re: message read pointers betwixt ecweb & synchronetterminal iface
By: echicken to Khelair on Fri Nov 21 2014 00:57:07

JavaScript Object Notation (JSON) is fairly easy to work with, and nothing to be dreaded. In fact it's probably what I would end up using for this. Don't confuse JSON itself with the JSON DB, which would be overkill here. One can easily just save a JSON string to a file, then read it back later.

I'm actually starting to learn quite a bit of it, in the coding that I've been doing. Haven't worked with dumping it toand from a string yet, but I assume there's a pair of methods that make it pretty simple.
The JSON DB is, indeed, where the confusion came from. That was the beast that I was dreading here. Thank you for pointing out the different terminologies to me.

Well, it's not really about that. It's easy enough to update a user's message pointers. I don't have any technicalconcerns about this. It's just a user-experience consideration.

Look at it this way:

this sub. As far as my pointers are concerned, I've seen all of the new messages in this sub (but I haven't really, just yet - there are seven
others that I haven't seen, which won't be caught by my new scan the next
time I SSH into the BBS.)

Yeah, totally got it. I have forgotten that the interface was threaded. I will transgress no further in this, however. I've got a tab open to the interface now.

Of course this might be what people want or expect. I just don't think it's ideal. (Though neither is the way it currently ignores pointers altogether.) I can think of a bunch of ways to work with and around this, but they all involve compromises of one kind or another. This is why I shrugged and left things as they are for now.

I've talked about the problem with my buddy. As I said, he's a dev, and he totally gets the problem now. I'm going to see if I can't find out what his preferences are, because when it comes to UI/UX, quite honestly, I suck. I'm good at text interfaces, and I'm good at coding internals, but I am terrible at knowing what a user (other than myself) wants. There's a chance I'll be able to bring him into the discussion here soon, we'll see if that happens or not.

What I could and probably should do, without complicating things unnecessarily, would be to add a visual indicator of which threads have unread messages in them. It would only be good until you browsed away from the current page, but would at least tell you where to look while you're there.

That'd definitely be a great improvement in general.

A previous version of ecWeb had a "new message scan" that was sort of okay. Maybe that could come back. I can't say that I really want to put any work into this right now. I've got other fish to fry.

I totally understand. Actually, I've been hampered in my career search lately because I haven't been working on any web apps, only console and system level stuff... Would you mind if I tinkered a bit myself?

Whatever you find there may or may not be informative in any way. It's really just a convenient place that's set aside for storing arbitrary per-user data files, as far as I know. (With the exception of the ptrs subdirectory there, but ignoreit, because we'd only be operating on those files through abstraction.)

Gotcha.

Well, I do care about design and user-experience, which is why I didn't foist something on users that might lead to a confusing diddling of their pointers.

Yeah, that's a problem that's gonna take some thought. I'm starting to have a few ideas, though...

Scoffing and finger-pointing don't bother me too much. That's just a part of the "fun" of this shit. I'm just more tolerant of it when it's about some glaring inconvenience-causing or security-compromising error than when it's about a missing feature. If the suggestion has merit I'll likely implement it eventually, no matter how I heard about it.

:)

That said, "eventually" could be a long time.

Of course. This world has a way of making things that matter to us personally take quite the back seat to the things that we need to do to stay alive and afloat, that keep this giant machine destroying this wonderful planet that we live on.

ecWeb is not without its multitude of flaws, and I can't say I'm particularly wild about it in general. It does however have a lot of features. If it's missing one and you suggest it, then sure, I'll look into it. If you scoff and point fingers because I didn't think of every possibility right off the bat, well ... fuck yourself, andI'll get to it when I get to it. That, sir, is just the manner in which I locomote.

That is a sentiment I can understand and respect. :) Here's my take on ecweb: best alternative that I've seen so far. I like it, and when I've got the ability to have web service available, it's the one that I put up. Right now I just can't have any web servers open due to the restrictions on my network. When I said I stopped using it before, I didn't mean that I stopped offering the option; I've left it up, and multiple people used it while I still had it up. It was just a problem that I'd noted, so I stuck to text.

It's entirely possible that you or other people have raised this issue with me and that I've forgotten about it. I don't however remember any big ecWeb-and-pointers discussions having taken place. If you do stop using something because it's lacking insome way, it never hurts to make a feature request. If you did and I ignored it, well ... heh, sorry. :|

Not even sureI mentioned it before, actually. No worries.

Anyway, I'll see what I can do about this the next time I'm poking around in ecWeb's intestines and lower bowels. If you or your friend have a particular vision for how things would look or operate re: