For a better way to store IRC logfiles.

So, suppose I have a long discussion on #kde-in on how to use the rebase command for git. Also I have a discussion on #kde-git in parallel. Then suppose after 2 years I forget some of the many uses of git rebase that I had discussed 2 years back. But I have a freshly installed distro and I did not care enough to backup that particular log file. And yes I feel frustrated.

So what to do about this? I feel Konversation should help the user by saving log files in an intuitive manner. Like after a ‘long'(definition of ‘long’ can be debated) discussion is over Konversation should recognize this and should ask the user for a file name for the log-file. The user should also be able to provide keywords/tags to associate with the conversation. This would provide the user for a more intuitive way to handle IRC chat logs, helping the user to take a backup of the required logfiles only.

Also there should be a way for people on IRC have their own chat history available. And this should not be limited to only logfiles stored in the hard disc. IRC chat can be synchronised with email accounts, so that chat logs can be viewed anytime without the headache of having to backup data. Will have to think about this later. Do leave your thoughts on this. 🙂


6 thoughts on “For a better way to store IRC logfiles.

  1. Dear god, please no.

    For people who use IRC in a daily matter, as channel operators, network admins, IRC OPs and so on, this would be horrible. When I would get promted after each longer conversation, I would get prompted at least 4 times a day. This would be very disturbing for my normal workflow. I am not against the possibility to save them, but it should be opt-in, never a default setting.

    Konversation already offers a log view (CTRL+O), and you can even configure it to display the logs in your favourite editor and search through them and whatnot. Having the files also available as clear text is a good thing, so you can grep through it if needed.
    So both average users (having log files inside the client, being able to search through them) and more experienced users (having the possibility to grep through clear text files) are happy.

    Since it is plain text, a search via nepomuk is not a problem at all, at least not if the files are indexed. If you think that there is a need to add additional tags to such a conversation, I don’t see a problem with an optional save dialogue allowing this, which is displayed when the users tells the client to do so. But honestly, with an indexer such as strigi this should just not be needed on plain text.

    The logs are stored in your home directory currently, so it will be taken along to a new system when you have a backup of that. If you don’t: I don’t really know why you expect the logs to still be there, all your other client side data is gone as well. And there it doesn’t come as a surprise. E-Mails are of course something different, since they are stored on a server. IRC conversations are, fortunately, not stored on a server unless some people (e.g. ubuntu channels) took care of that.

    Also I have no idea how you expect “IRC chat can be synchronised with email accounts” to work. It looks to me like a nice mixture of two things who have absolutely nothing in common.

    Sorry if this sounds rather direct, but: The situation is in my opinion not bad as it is. There are logfiles, there is easy access to logfiles, you have to back them up if you want to keep them when moving to a new machine, as every other data you might have.

    If you are interested in having the logs available from everywhere: most advanced users either have a bouncer (such as ZNC or bip) or irssi or something similar in a screen session on a server. Then you have all your log files centralized. And yes, this might not be end-user friendly, but sorry, IRC was never _the_ end user friendly protocol in the first place. And I don’t think that one needs to change this, at least not when it would disrupt the workflow for the experienced users who have worked with it for more than ten years by now.

    tl;dr: Logs are already easy accessible, logs are stored in a sane way, logs are in a format which allows indexing by already available KDE technology, logs are, as any other data, of course lost when not backed up. If the users wants it, centralized logs are available. I see no problem here, sorry.

    Kind regards

    • Thanks for the reply. These thoughts had just crossed my mind and after having gotten some positive feedback I figured I could blog and get more views. I still do think it would be nice to have some way to track conversations involving me and store them as chat history in GMail for example. And yes this should certainly be an opt-in feature. Anyway thanks again for your feedback. 🙂

      • Hi there,

        I currently don’t see why it has to be a mail account, but since it’s plain text: if your mail service supports so and has an API, it would be rather simple to implement. (Well, in the worst case the service does not even have to support it. You just push it there as a mail. Which doesn’t strike me as a very logical thing to do, but probably there is a valid usecase for that, and in the end the user is right. So if the users wants it, I guess he can have it)

        Maybe storing it in a cloud service (KDE has someting rather good integrated with mycloud, as far as I am informed. As I don’t need it I unfortunately didn’t try it so far) would be an option. I personally would never do this due to privacy concerns, but for people who want that: why not. Maybe the problem here is that the logfiles are in a dotfolder, which the user might not know. But this is also the case for, as an example, instant messaging chatlogs from kopete. So either the client side of that cloud service should check for that (common location for chat logs maybe, then have a checkbox to store chatlogs to the cloud) or we would need a standard location for chatlogs. Based on how well more important cross-desktop standards work, I think that we are far from this 😦

        As said, the chatlogs are already there and plain text, so moving them to $wherever should not be a problem after all. As long as this place supports storing of plain text, that is.

        Have a look at mycloud, maybe it’s exactly what you want. Otherwhise, if you have a 24/7 running server around somewhere, I recommend you go through the hassle of setting up a bouncer once (there are rather good tutorials available for most server distributions) and connect to it. You will never use your logs again (unless you don’t backup your server and it breaks, that is)

        Kind regards

  2. I don’t think this is a bad idea at all. However, prompting the user for the file to be saved would be a little too much. I think all this problem can be solved with an appropriate Nepomuk plugin that uses scribo to do keyword extraction from your IRC logs and tag them accordingly, and index them for later searches through Krunner.

  3. In general an interesting idea.

    I agree with some of the critique above though. So here’s my 0,0155 €:

    The automatic conversation detector of an interesting thread should be an option you can opt in and with two possible sub-options (see below). If you were the one to ask a question it should take that and propose it as a keyword — e.g. sending ” Hey, does anyone know how to get Konversation to work with Nepomuk?” would trigger the detector because it includes a question (“does anyone know”, “how to”, “?”). As you suggested it could be triggered also by the user talking a lot for a while.

    When saving the user would be presented with the option to tag the conversation with keywords and fine-tune which lines should be included and which not. Automatically the name of the channel (and store its link e.g. irc://, date (and time) (using Zeitgeist?), people who were participating in the discussion and the guess of what the chat was about would be suggested. While the system could guess from when to when your conversation was active, it’s never perfect especially since in the mean time people are often talking about unrelated things, so the user should have the option to exclude and include lines. Of course the names tag suggestions would be recalculated when the user would tweak the lines of the conversation.

    I don’t know if saving it into a separate file makes sense though. I think it would make more sense to use Nepomuk’s tagging system to tag certain portions of the standard logs and therefore making these easy to find and present. So when you would later on search for e.g. “Nepomuk”, you would find that conversation.

    Suggestions for UI:

    1) Pop-up notification

    As in your initial suggestion, you could have a pop-up window when the conversation detector triggers. Some people might like that (personally I wouldn’t), but in any case you’d need it to have a saving dialogue anyway.

    2) Button with notification

    Another option would be to have a small button somewhere in the interface. This button would change in appearance if the conversation detector would trigger. But the user would be able to ignore it (maybe cancel it with a middle-click) and also able to press it and open up the discussion saving dialogue even when the detector doesn’t trigger.

    3) Panel

    Especially people who use Kopete full-screen might want to be able to move this saving dialogue into a panel and have it always present at the side of the screen.

    I think a combination of all three would be a possibility. Personally I’d like to have the button under 2) placed by the message-entry textbox and when I press it the panel under 3) would trigger, so I can select the lines side-by-side with the chat panel.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s