14 Responses to “#ossasepia Logs for 27 Apr 2020”

1. spyked says:

   May 14, 2020 at 7:52 a.m.

   Re.

   spyked: diana_coman, tbh I haven't yet used the mpwp-based log frontend enough to stumble upon any missing functionality. I'll give it a try for a week or so, I'll let you know if I find something missing

   It's been well over a week now, so I guess it's not a bad time to gather some thoughts on this. I'll begin by stating the obvious, i.e. that it does the job. I haven't found any fundamental pieces to be missing, but there are a couple of things that bug me in day-to-day use, namely: a. the viewport; b. the lack of a mechanism for day-to-day scrolling.

   Regarding a): I know I'm the weird kid who doesn't like two-column WP themes, but adding the logs in turns this into a four-column viewport (the nickname, the loglines, the date and the sidebar). The flexible logline column helps, but I happen to often read the logs on smartphone screens, which I suppose makes this my own problem. I'm not sure how it can be fixed, but just for the record, I'm a sucker for the old btcbase design.

   Regarding b): I hated it when Ben did this "monthly log pages" approach for his logger, and I hate it equally now, since by mid-May, the log page is long enough to require substantial scrolling effort in order to get to a particular conversation piece. Yes, I'm aware this is actually an issue with HTTP's resource access model, but we work with what we've got, and logger frontends could at least make this part configurable -- in other words, given a time interval X-Y, why is it that just X is configurable? The day-level granularity works better for me than month-level, otherwise... This may perhaps hint at a reason why blogs aren't really suited for this kind of thing; statically-generated log pages work about as well, they're missing the comment section, but that aside, they offer about as much flexibility in using the logger.
2. Diana Coman says:

   May 14, 2020 at 9:18 a.m.

   Thanks for the feedback.

   Re a) - do you mean you basically don't want to have anything other than the text on screen when you read the logs? This is indeed ultimately dependent on your screen so perhaps worth digging at it from that end to set it as you want it.

   Re b). - this might be fixable actually, if I understand correctly what it is that bugs you. It's not all that hard to add some anchors at the start of a day for instance. The question I have here is more one of ...what's the relevance of timestamps (days, time, whatevers) in this context? It's not even "speakers' own local time" given time differences and all that so dunno, to me it sounds like what you are in fact after is a personal (aka for you) bookmark along the lines of "this is where I left reading last time so get me directly there" . Which I'd say you can easily set, just use the anchors for the respective line, doesn't that work?

   For the record, for my sin of having made use of that piece of shit that is currently running ossabot, I am now stuck with all sorts of decisions to make along the lines of "which stuff to break" and "whose links to break". Such pleasure, I can't recommend it enough to anyone lacking a fresh time&effort sink really.
3. spyked says:

   May 14, 2020 at 10:10 a.m.

   Re a): I mean that I'd rather loggers contained only the contextual information needed to read the logs, e.g. I see no need for the blog sidebar in this context (or at all, but I won't go that far). So now in order to get that out of the way, I need to add horizontal scrolling in the mix.

   Re b): that works, but my point was that this cut-off (day, month, whatever) is arbitrary anyway, so why not make it configurable? Unfortunately I see no quick way to add this to MP-WP, as the "post/publish" paradigm is incompatible with this "flexibility" requirement (what are you going to do, add a log post/page for each user preference?). To get this, you'd have to write a piece that dynamically generates pages from the log database, using GET parameters as configuration knobs for e.g. the number of lines and/or the time interval to be displayed. But then you necessarily lose comments for those pages, unless you want to hold a comment section for each URL/GET parameter combination, which would be just nuts.

   But well, this discussion from principles probably goes a tad too far off. Nitpicking aside, it does the job, I'm not really complaining.
4. Diana Coman says:

   May 14, 2020 at 12:32 p.m.

   I mean that I'd rather loggers contained only the contextual information needed to read the logs

   I think this is actually a slippery slope as a principle because it goes towards the sort of isolation that is not all that healthy "this thing here is on its own, without the idiosyncratic context of the people involved" (admittedly, this is pushing it further than you did anyway, but since we are doing by your own statement a discussion from principles, the push is meaningful here). Back from the principles and to the very practicals, I can see the reading on smartphones though pushing this sort of "get everything else out of my way" simply because of less screen space, sure.

   this cut-off (day, month, whatever) is arbitrary anyway, so why not make it configurable?

   Because there is no good reason for it to be configurable. The fact that it is arbitrary does *not* mean by itself that it should be configurable, all it means is that *someone* must make a choice really. And for the record, if you go the route of "if it's arbitrary then it should be configurable", it seems to me that you are exactly avoiding having to make that choice and in the end going precisely the route that leads to 10001 "configuration options" that nobody ever needs or uses or even fully knows wtf they do anymore. And in the process, you add a lot of complexity for no good reason. No, I don't think it even *should* be configurable as you mean it, not at all. There should be flexibility allowed and there is - you can literally set it to go directly to whichever line you want (and moreover the links are even in sequence so you can script it if you want something specific).

   Honestly, I don't otherwise mind even complaints, lol. Glad to hear though that you do find it does the job even as it is.
5. spyked says:

   May 14, 2020 at 1:09 p.m.

   I think this is actually a slippery slope as a principle because it goes towards the sort of isolation that is not all that healthy "this thing here is on its own, without the idiosyncratic context of the people involved"

   I'm not 100% sure I'm reading this right, but as I was saying in the linked article, that idiosyncratic context lies in the visual field as well as the references, up to and including that link to the blog on all its pages.

   Anyway, perhaps I'm repeating myself: I can definitely see how one could find this context useful as part of their immediate visual field. I find the nuisance, both in the horizontal space it occupies and in the extra bits of information, to offset the usefulness, but that's just me. Then again, I don't especially like having all my stuff in the same place, probably because the set of things I need in one places at a given time is so different from now to the next half-hour, so... I end up working with "this thing here on its own" anyway. Which gets me into gory details, such as whether I'm doing the first read or the second; sure, I might have to surround myself with a pile of dictionaries when I read a book in a foreign language for the first time, but on subsequent reads that's really not going to be necessary.

   For the record, I also read (b)logs on Firefox and in w3m. The latter, in particular, shows the logs precisely the way I want them to, but only because it never puts divs side by side, so the sidebar ends up right above the footer.

   Because there is no good reason for it to be configurable.

   Ok, no argument here. I mean, I would like to be able to configure such things as the period of time spanned by a contiguous set of log lines (or at least I think I do!), but I wholeheartedly agree it's a matter of choice, as is the design point above, actually.
6. Diana Coman says:

   May 15, 2020 at 7:06 a.m.

   Ah, I think I get at least slightly better what & why you are after. Though indeed, it sounds to me more like a very specific matter, to be set just-so on user side. Anyways, thanks for the feedback again, it's been quite interesting to hear.

   Some time this month I'll sink some more time into tidying the remaining bits on this too - adding a regular raw dump of the logs db for instance and then I'll finally turn off the old logger and good riddance there.
7. billymg says:

   May 15, 2020 at 6:46 p.m.

   When I first saw this project on Trilema I assumed it was meant for archival purposes (i.e. if it's in Trilema's mpwp db then it's permanent). Until seeing it hooked up to sonofawitch I didn't think it was meant to be used in place of what's at logs.ossasepia.com. Here are a few of my thoughts/observations on it:

   - It's missing a search box. This seems like a critical feature for a logger that's to be used primarily as a reference tool (although it would be useful in the archive use case as well).
   - The log content feels out of place when mixed in with articles written by the blog's author (e.g. when refreshing ossasepia.com to see a random article each time).
   - If I had an IRC channel and I archived its logs on billymg.com, the first thing I'd do is separate the logs from the articles. They would share the same database, but there would be two different ways of browsing on my http://www. So that viewing the archives for a month or category would show only blog articles, with the logs filtered out (or perhaps displayed differently). And there'd be another interface for viewing logs, which would show only that and have a different layout tailored to the logs (e.g. full width, no sidebar, a smaller header, etc.). Perhaps they have their own subdomains, so there's billymg.com and logs.billymg.com, with a link somewhere in the interface to go back and forth between the two.

   I guess overall I do see merit in merging the two types of content (I mean, it's always been common to see links to the logs from blog articles and vice versa), but I don't think just dumping the logs into the "post_content" field without any further modification to how mpwp handles and displays them is the right approach.
8. Diana Coman says:

   May 15, 2020 at 7:00 p.m.

   Thanks for the feedback. Out of curiosity - why would it be for archival purposes and why would the 2 be different really? If anything, the way I see it, the blog provides the option to comment on the logs, making them all the *less* archive and the *more active* than that shifting-sands thing that only serves to ensure headaches down the line really.

   Re search box, mhm, I'm still pondering this one. On one hand there's always still google with site:ossasepia.com so not like one can't search. On the other hand, it being google...I can see the point. I'm still thinking what to do (if anything) about this.

   The log content feels out of place when mixed in with articles written by the blog's author

   In what way/why? I suppose I can see the point for those where I'm not active, but in #o at least, dunno, I surely make more than 50% text in there anyway.

   the first thing I'd do is separate the logs from the articles

   Well, they *are* separated with their own category. I'm not sure I really follow otherwise - it seems to me you have a very, very strong view that "logs are not articles" and ..why not?

   So that viewing the archives for a month or category would show only blog articles, with the logs filtered out (or perhaps displayed differently).

   This is actually a not-bad idea otherwise. And part of why I was asking you a few days ago re archives, lol. Yeah, I still need to spend some time to sort the archives out, this much is sure.

   And there'd be another interface for viewing logs, which would show only that and have a different layout tailored to the logs (e.g. full width, no sidebar, a smaller header, etc.). Perhaps they have their own subdomains, so there's billymg.com and logs.billymg.com, with a link somewhere in the interface to go back and forth between the two.

   Uhm, why? Why would I re-create the headache, I don't get it. Sure, if I wanted them separate, I could have simply set up a mp-wp instance on logs.ossasepia.com, set there a theme of the sort you suggest and be done with it easier and making the separation real since IF a separation is warranted than what's the point in keeping them in the same database and just pretend-separate? But honestly, I still don't get it: how is logs-text a different sort of text than articles text and why exactly should my own chan end up logged somewhere else than on my own blog?

   I don't think just dumping the logs into the "post_content" field without any further modification to how mpwp handles and displays them is the right approach.

   Why exactly isn't it?
9. Diana Coman says:

   May 15, 2020 at 7:25 p.m.

   For the record: no, it's not "dumping the logs in the post_content field", or they wouldn't end up in a table and with the links per line, you know?
10. billymg says:

    May 16, 2020 at 3:10 a.m.

    > why would it be for archival purposes and why would the 2 be different really?

    Really they shouldn't, to me what's at logs.ossasepia.com works equally well for archiving (so I admit I was never really sure about the "why" behind bringing them into mpwp).

    > the blog provides the option to comment on the logs

    I guess I don't see how this is that much different than linking to a log line in IRC and having the channel bot replay it inline, but perhaps the difference is that it removes the meta-discusison from the flow of the logs, and maybe makes it feel more permanent in that way.

    I agree this might be a nice feature, but I could potentially see it better executed in the existing logger. Imagine if there is a small column all the way on the right side of the logger with a link to add/view a comment thread per log line. If there are no comments, nothing is shown until you hover a log line, which then reveals an "add comment" link. This goes to a page with that line highlighted and a comment box exposed. If there is already at least one comment, a simple count shown in parenthesis, like (3), which is also a link to a page with that log line highlighted and the current meta-thread plus comment box shown.

    If one wanted to they could also include a "recent comments" sidebar pane (similar to what you have on this blog), so that when one is reading the logs they also see at a glance the recent meta-discussions.

    > there's always still google with site:ossasepia.com

    This to me is not even close to an adequate substitute. The main reason being how much google's algo mucks with the order of results (and who knows how often they index and how reliable it is). Not to mention you lose out on the very useful "from:username search query" syntax.

    > it seems to me you have a very, very strong view that "logs are not articles" and ..why not?

    They're the minutes and reading minutes just feels very different than reading an article. The minutes are the author's raw thoughts in realtime, an article is the distillation of that. They're both useful and information dense, but to me they read very different.

    That said, I would personally love to have the ability to embed a section of logs into a blog post without spending a lot of time marking it up. This way I can write an article and include a thread for context. Not yet sure how this would implemented though.

    > Sure, if I wanted them separate, I could have simply set up a mp-wp instance on logs.ossasepia.com, set there a theme of the sort you suggest and be done with it easier and making the separation real

    If the goal is to use mpwp instead of what's currently at logs.ossasepia.com then to me, yes, this would actually make more sense than having them in the same db as articles. If the goal is to facilitate a kind of meta-discussion on the logs then I would consider something like I described above with the discussion feature added to the logger, rather than the logs added to the blogging platform.

    To be completely honest though, I still don't really see the goal or problem being solved for, and perhaps that's why I'm having a hard time evaluating what is/isn't a good solution.

    > it's not "dumping the logs in the post_content field", or they wouldn't end up in a table and with the links per line

    Yes, it's being marked up, sure, but just as you markup an article by hand, in the end you're still just storing the blob in post_content. Not necessarily a bad thing, but rules out future "return all log lines from userX" or "return all long lines from start_timestamp to end_timestamp" type features (the latter of which could be useful in an "embed log thread" feature for articles).
11. spyked says:

    May 16, 2020 at 6:43 a.m.

    From

    But honestly, I still don't get it: how is logs-text a different sort of text than articles text

    and

    I guess I don't see how this is that much different than linking to a log line in IRC and having the channel bot replay it inline

    what I'm drawing is that a. logs are text and b. logs are discussion, but additionally, c. meta-discussion (e.g. comments) is also discussion. So OTOH, it seems that this interplay between IRC, logs, blog articles and comments introduces some headache in following discussions.

    FWIW, I see a separation between articles, as in long form writing, and discussion, as in replies-to-replies-to... in the form of lines/comments. I don't think the separation is strict (I've added log pieces into my articles, after all), and furthermore, beyond that I find it hard to categorize "discussion" into comments and log replies (at least I don't see a criterion for that). So I guess I'd prefer to stick to the old method of replying to articles via comments, and to log lines via IRC. But yet again, I'm going into the realm of preferences rather than some well-justified method, so... well.
12. Diana Coman says:

    May 16, 2020 at 7:38 a.m.

    @billymg

    to me what's at logs.ossasepia.com works equally well for archiving

    Except it totally, utterly and *by design* doesn't work well for archiving unless by "archiving" you mean a .tar.gz file, in which case it's really *that* which works well, not the whole flask-powered yet-another-webpage-to-feel-important. And there's otherwise fundamental breakage in the design which makes it not work well (one of the reasons I say it's a piece of shit): what sort of archive is that which is basically shifting sands, meant in the best of interpretations as a quick display (eg "everything in the front; did the chan stop? sucks, you are stuck with either dropping *its history too* or keeping it there in the way of everyone because guess what, there's no idea of archiving, no) rather than any archival.

    I guess I don't see how this is that much different than linking to a log line in IRC and having the channel bot replay it inline, but perhaps the difference is that it removes the meta-discusison from the flow of the logs, and maybe makes it feel more permanent in that way.

    Having a different place for the meta-discussion is an important and very useful difference, I should say. There's no "feel more permanent" from it, not even sure how that would be or what the link would be there. The permanence part comes from having each article accumulate as it does and then keeping it *as such* but *in its proper, logical place* for as long as one keeps the blog up at all - there's no spurious and unhelpful imposition for instance that all logs (even old, inactive ones) should get the front page or something. And moreover, it's an alternative - readers *can* interact with the logs as they interact with any other article, no need to get on irc, learn about the bot and about citing and so on. The whole breakage in the flask-powered logger has deep roots and I don't want *any* of them surviving because they are all poison.

    I agree this might be a nice feature, but I could potentially see it better executed in the existing logger. Imagine if..

    I imagine and I shudder. And do note that what you are describing there ends up towards... "like on this blog" so seriously *why would you even go that route*? Why re-create there instead of adapting here (if even needed to adapt that much)? Let me ask it also from the other side - what's that great reason for which I should add a whole new *pile of stuff* to everything else I'm maintaining? And by pile I mean pile, without exaggeration, to list but the main stuff: a. flask and all its dependencies (there's about 12 of them iirc!) b. postgres when everywhere else I use mysql c. another web-displaying application when there's already mpwp in use and enough to maintain as it is. The question is always - why *add*, not "why not keep feeding this sucker too since it already sucked something from you". Seriously now.

    In case it's not clear, I should perhaps add that I don't keep anyone back from running whatever logger and display they want to, of course. I'm not even kicking out any bots from my chan, nor do I see so far any reason to.

    This to me is not even close to an adequate substitute. The main reason being how much google's algo mucks with the order of results (and who knows how often they index and how reliable it is). Not to mention you lose out on the very useful "from:username search query" syntax.

    There is that. So possibly a search box would be useful indeed.

    They're the minutes and reading minutes just feels very different than reading an article. The minutes are the author's raw thoughts in realtime, an article is the distillation of that. They're both useful and information dense, but to me they read very different.

    Lots of things read differently and they are no less articles for that. What, does it really read the same if I write about code for instance as when I write about travel? Not to mention I even have around some fiction pieces, as well as some - gasp - conversations dating from before the logs. So what, those conversations should now be moved somewhere else because they weren't distilled thoughts or something? I think the narrow expectations re what an article can/should be are not helping the reader any and certainly not the writer, way better without them. If forcing the logs on the blog even *helps* with shedding such narrow expectations, all the better, I clearly should have done it earlier!

    That said, I would personally love to have the ability to embed a section of logs into a blog post without spending a lot of time marking it up. This way I can write an article and include a thread for context. Not yet sure how this would implemented though.

    What do you mean? My bot does it automatically, not like I spend time marking up any log lines, ugh. And for the record, the log content is basically stored in raw format as it should be in its own db; the mpwp articles are simply a display of that raw content and as such different - though by design a *permanent* display as for sane people, indeed.

    If the goal is to..

    The goal is to cut out needless complexity, brokenness by design, unhelpful impositions and various other dead weights that I got myself saddled with for using the wrong thing. And if I need to cut out deep to get rid of poison, then deep it shall be cut.

    Not necessarily a bad thing, but rules out future "return all log lines from userX" or "return all long lines from start_timestamp to end_timestamp" type features (the latter of which could be useful in an "embed log thread" feature for articles).

    No, it does not. As I say above, the *raw log* is still stored as a raw log, there's no mixing the 2, nor any good reason to. The article in mp-wp database is *one permanent display* of the raw logs but this doesn't mean that I go the idiotic way of discarding the raw lines, no. What I discard is spurious and needless stuff that doesn't add any benefit, not sanity.

    @spyked What you say there seems to turn around the fact that it would be easier to keep each conversation in one single place (either irc or blog). Which is certainly true, can't argue with that. But conversations are always messy and enforcing this sort of tidy up comes mainly at the cost of narrowing the conversation after all - think of it, someone reads the log and it's anyway apparently a terrible act of courage to comment even if the box is right there under the logs, let alone if they have to get on irc, figure out chan, voice, bot-citing etc.
13. billymg says:

    May 16, 2020 at 4:51 p.m.

    @Diana Coman

    Ok, I think I understand the aim of this much better now.

    - The standalone logger is its own maintenance nightmare, so why add this to an already large (for the number of hands available) list of tools to maintain.
    - MP-WP already exists as the "display text on the web" tool, and has been doing this job well and reliably for over a decade, so if there's another category of "text to display on the web" (the logs in this case), mp-wp should be adapted to handle it, rather than adding a new tool/stack to the mix.
    - The standalone logger doesn't facilitate discussion in any way, and although one can still connect to IRC and join the channel this is a huge barrier to entry for those not familiar with the tools. Whereas the blog provides a familiar html textarea that anyone can use to engage.

    Thank you for condensing it all in your reply, I think there was a lot of context I missed when the tool was originally being spec'd and built. Knowing this I now see how it fits into mp-wp, and the purpose it serves aside from reducing maintenance time and lines of code.
14. Diana Coman says:

    May 16, 2020 at 6:39 p.m.

    Well summarised indeed and the discussion is good to have anyway as it's now in the clear and can be found here by anyone who comes in later/asks the same, so it's all for the best really!