Please wait...
By the way, I did go ahead and make the change, so you'll be seeing it appear soon. "Reply" will continue an existing thread; "Enter message" will tell you that you are beginning a new thread and prompt for a subject. I expect it will take a few revisions to evolve into something that makes everyone happy but we're going to go in that direction.
Sun Sep 22 2024 17:38:56 EDT from IGnatius T FoobarI don't know if anyone is maintaining that package. In fact, we've removed support for LFSH so the packages will probably go away at some point. I could see a compact build of the client reappear at some point though.
Gotcha. I'll continue using the package version for the foreseeable till the updated text client is released fully and give that a try. Right now happy on 1000 so I've not upgraded anything in the past little bit. Don't want to have to re-do some tiny customizations that may get overwritten in the webcit upgrade as well.
I do severely hope that Modulus is too small thing disappears in later builds.. .annoys me to no end...
2024-09-27 11:16 from Nurb432
But why do we want an X account? :)
So the above message (in a different room) was a top-level post. It will display as a new thread if a threaded view is introduced.
This is not a scold, it's end user research. Since I know you're online right now and just posted that, while it's fresh in your memory can you tell me which client you are on and what went through your head as you entered that message using "enter message" instead of "reply"?
The goal is to find a way to make the user interface discourage entering replies as top-level messages, without being unreasonably intrusive.
i actually did hit reply, unless it was a bad mouse click or something unintentional on my part, but not sure how it would have clicked THAT far off to hit "post" at the top of the page..
i'm using the regular web client, via chrome ( i know i know )
Fri Sep 27 2024 11:20:27 EDT from IGnatius T Foobar2024-09-27 11:16 from Nurb432
But why do we want an X account? :)
So the above message (in a different room) was a top-level post. It will display as a new thread if a threaded view is introduced.
This is not a scold, it's end user research. Since I know you're online right now and just posted that, while it's fresh in your memory can you tell me which client you are on and what went through your head as you entered that message using "enter message" instead of "reply"?
The goal is to find a way to make the user interface discourage entering replies as top-level messages, without being unreasonably intrusive.
Always possible, but i normally blame myself.. :)
I have had cases in the past on other web apps where a slow refresh happens for whatever reason, and what i thought i clicked on really wasn't. Just thinking that is pretty far away in the interface for that, but its always possible. The thing i support at the office is really bad for that actually.
And with the mouse issues of late, i dont want to say for sure it was a bug. But might be...
Fri Sep 27 2024 12:28:57 EDT from IGnatius T FoobarOk so possibly a webcit bug.
This is a reply to your message, which definitely used the Reply button, on the version of WebCit Classic currently running on Uncensored. Let's see what the headers do.
i dont think i have ever seen it do that before, but never really paid that much attention so could have easily missed it. And, since none of us are good about subjects around here.. :)
FYI It didn't as of a post i out in random musings as of Tue Oct 01 2024 07:38:04 EDT didn't prompt or force, acted like it did before. Unless i misunderstand what it should be doing. I do see that subject label has (optional) disclaimer now. I don't think it did before?
Didn't realize you added that until afterwards, when i came here to read new posts.
Ok, as of right now, the version of Citadel running here on Uncensored will begin prompting for a subject whenever you use the "Enter message" command instead of "reply"ing to an existing message. It also seems that if you reply to a message with an empty subject it will prompt too. I'm not sure whether that was intentional.
Doh, sorry. too much stuff going on today at the office, i should not be trying to be on here too :(
You're using the web interface. It didn't change. And yes it always had the "(optional)" label.
Subject: Atomicity, a-to-micity... (apologies to School House Rock)
Many years ago, our old friend Michael Hampton aka IO ERROR (yes that guy, the king of Stack Exchange, rest in peace buddy) took the time to add a single module to the text client that handles all communication with the server.
At the time, there was still an assumption that there would eventually be multiple standalone clients. We hadn't yet realized that the Web would be so incredibly pervasive and evolved that standalone GUI interfaces would become a thing of the past.
The text client's protocol library has a function CtdlIPCGenericCommand() that performs transactions with the Citadel Server in a completely atomic manner. He also wrote functions to wrap each and every server command that existed at the time. It's quite nice compared to some of what still remains in the text client from my late-1980s garbage coding style (once described by a hostile critic as "did you learn to program in C by reading a book on BASIC?"). Some of that still remains but it's gradually being worked out. Very gradually. It's not a high priority.
At the time, IO said "This wrapper should be able to handle any server command except CHAT." That's because the chat protocol at the time simply opened a connection and kept the transaction going until the user exited chat mode.
It was pretty awful. Later on I improved the protocol to make chat operations atomic again, but IO wasn
't around to fix the client library. Because he died. But not from that.
--- end of exposition, start of what I did last week ---
While killing time in the evenings in a hotel room during last week's business trip, I decided to remove all of the places I abused the CtdlIPC_chat_send() and CtdlIPC_chat_recv() commands to implement new functionality. Everything, and I mean everything, now uses the CtdlIPCGenericCommand() call, or functions which wrap it.
This means that it's now possible to implement alternative transports with ease. All we have to do is write those transports and build them to the same internal API. So now, let us allow our imaginations to run wild. What can we do?
* UDP is all the rage these days. HTTP v3 uses it. mosh uses it. It behaves in a more deterministic way with mobile clients that might have spotty connections, changing IP addresses, etc. And guess what -- we own port 504/udp as well as 504/tcp so we could implement a connectionless protocol.
* How about a mode that carries Citadel client commands over HTTP? This would also do a good job at handling clients with spotty connectivity.
* Citadel protocol over I2P-SAMv3 messages would probably use the darknet far more efficiently than tunneling TCP.
* I don't know much about packet radio, but I'll bet we could have all sorts of fun here.
--- end of that, start of call to action ---
Anyone interested in writing some code? Or any other ideas?