@firstname.lastname@example.org (#3ezvila) Nah, that was just an example. 🙂 I’d probably go for “$n months or $m twts, whichever comes first”, both variables being customizable. I mean, there’s no point in “paginating” a feed if there’s very little traffic.
twtxt-2021-10-25.txt: Feed of twts starting at 2021-10-25. For now, this is the “current” feed.
twtxt-2021-10-25.txt keeps growing for a while by appending new twts at the end.
Once twtxt-2021-10-25.txt is “full”, we add a next field to its metadata which points to …
… twtxt-2021-11-01.txt, which is initially empty except for a prev field that points back to twtxt-2021-10-25.txt. From this point on, twtxt-2021-11-01.txt is the “current” feed. It keeps growing in the same way. Eventually, it’s full and superseded by the next (partial) feed.
twtxt.txt could then be a symlink to the “current” feed file.
Non-current feeds could now indeed be considered as “archived”: Nothing ever changes in them anymore (except for metadata maybe? What if I change my nickname or feed URL?)
Well, at least that’s how I’d go about implementing this in jenny. 🙂
@email@example.com (#r33kvxa) 🥴🥴🥴 To be perfectly honest, that slogan didn’t work out that well in the long run … 🥴😢 Keeping up with GTK/GNOME shenanigans is anstrengend (exhausting) as well. (Same thing with my VTE terminal btw.)
(#htxyltq) (In all seriousness, I don’t really drink a lot. It’s been ages since I was actually drunk, must have been my early 20ies. It’s just a small glass, 2cl, of good whisky every now and then, because I like the taste of it.)
@prologic (#7tmfmpq) Maybe. But in theory, it’s legal to append twts in the middle. Or, and I’ve done that myself a couple of times, delete twts somewhere in the middle of the feed.
I mean, doing that probably means that the partial feed I’m retrieving starts in the middle of a twt now, and that’s something that I can detect, so I can then fall back to just retrieving the full feed. But it’s not guaranteed. There will be subtle bugs, it feels very fragile. I’m not convinced that it’s worth the effort. 🤔
Now my laundry dryer is acting up. That’s one of those items that I don’t really need and, in retrospect, these guys were a huge waste of money. Sure, it’s luxurious and neat and fancy, but … Nah. If that thing dies, then it dies. (I just hope it doesn’t catch fire in the process.)
At the moment, it’d be rather easy to implement this in jenny: We could simply store the time stamp of the newest twt we’ve seen (that’s different than lastmods) and then discard older twts. I think @firstname.lastname@example.org asked about that a while ago, too. I think I didn’t implement this yet, because I simply didn’t need it. The twtxt world was so tiny that it didn’t matter. But you’re right, it’s going to be a problem in the long run.
Nobody ever really thought about “long term” in the twtxt world, if you ask me. I mean, it’s the same thing when writing twts. My feed keeps growing and growing … forever? Do I truncate at some point? Will all clients be able to handle that truncation? 🤔
I want to implement HTTP range requests next. That’s going to be interesting. Also, range requests and truncation probably don’t mix very well. 🤪 But I haven’t put much thought into it, yet.
tl;dr: I’ll put this on the TODO list after all. 👍
@email@example.com (#u6uumbq) There is no support for deletion, really. lastmods only affects retrieval of feeds (i.e., it sets the if-modified-since HTTP header), but when a feed is retrieved, then it is always processed in full. So, eventually, you get all twts that are present in a feed.
I’m curious, what is your use case for deleting twts?
That’s a netbook sleeve/case. That bright long-ish thing in the middle? It’s plastic. It doesn’t serve any purpose whatsoever. At least not from my perspective, but maybe from the perspective of the manufacturer: It’s made from that kind of plastic that dissolves over time. And that’s exactly what’s happening here. That thing is all sticky and gooey. So the idea is probably that I’m now supposed to buy a new one.
Well, screw that. I’ll probably try to cut it out and sew something else in there. 🤔
(#kwptbpa) Heh, her feed starts on 2021-03-19. That’s a few days after DST began in Seattle (2021-03-14). So we really don’t know if my hypothesis is correct, because we have not yet seen twts of her without DST in effect. 🤣
Seattle has UTC-8 in winter and UTC-7 in summer (IIUC). Let’s say it’s 9:34 AM in her local time. I suspect her script might be adding 8 hours to convert her local time to UTC – throughout the entire year. So her script will generate “17:34-00:00”. This is correct in winter, but one hour off in summer, when DST should have been applied: With DST, the script should have generated “16:34-00:00”. This would make her twts appear to be one hour in the future.
What’s strange is that some of her twts do have a -07:00 time zone. That would be the correct time zone at the moment! The bulk of them has -00:00, though, so there’s probably two different twtxt tools at work, one of them ignoring DST …
@prologic (#kwptbpa) “One hour” makes me wonder: Is this a DST bug? According to this, DST ends on November 7 in Seattle (that’s where she lives, according to her web site), so I guess we’ll see in a couple of days. 😁
@firstname.lastname@example.org (#ifphkga) Nothing wrong with asking. 😊 I think I might actually implement more aggressive subject “compression”. We should be able to remove those subject hashtags, they’re just noise. 🤔
(#ifphkga) Just for some more background: I wrote a StatusNet client years ago which worked very similar to jenny, with mutt as a frontend. That program did indeed truncate the subject lines – but it turned out to be a bit annoying in practice. It was always cut off a little bit too early. 🤣 So I eventually removed truncation altogether.
If Subject contains the full twt, then you can skim over conversations just by reading those lines in mutt’s index pager. I often do that. On the other hand, if they’re truncated, then the question is: Where do you truncate them? 72, 100, 140, 200? Some people have wide terminals, others don’t. So I decided: Okay, let’s have mutt do it. 🙃 (Or you could make it a user option, but I like to avoid those, because you quickly end up with a ton of options and things get very hard to test, because I myself don’t use most of them.)
The subject lines are already “compressed”, btw. For example, a full mention like “@” gets compressed to just “@foo”. Maybe it’d be possible to expand on that idea, like also strip the hashtags of conversation grouping. 🤔
@email@example.com (#5jejozq) No, of course not. 😊 I still take pretty much the same precautions as before (which is very easy for me to do, I can work from home 100% and all that; I don’t mind the masks and the distancing). But all those precautions don’t protect you, you can still catch the disease – so I was worried all the time (while doing stuff like buying groceries or using an elevator). And now that I’m vaxxed, this constant worry is gone. 👌
(I don’t know if I can get my point across. Damn language barrier.)
(#5jejozq) Since I got vaccinated, I stopped worrying about this whole corona business. Yes, I can (and probably will) still get it; yes, I can still spread it; but my life is no longer in immediate danger. That’s a big win, eh?