Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need new feature replay log #22

Open
fixegit opened this issue Jan 16, 2013 · 5 comments
Open

Need new feature replay log #22

fixegit opened this issue Jan 16, 2013 · 5 comments

Comments

@fixegit
Copy link

fixegit commented Jan 16, 2013

Hi
Need a function in achannel to replay logfiles written by server.
This is usefull between timezone ike US and Europe to see what was going on.
I think it should be only in a channel both has joined the bot and the user.
Then the user call '!replay myname 200' and the bot replay the last 200 lines from logfile was recorded from this channel. Only real messages no connection or status messages.

Let me know what you think about that.

Regards

Felix

@super3
Copy link
Owner

super3 commented Jan 16, 2013

Thanks for posting this on the Github page. We have plans to implement the logging feature in the bot, and will keep your feature suggestion in mind when we do. Note that this might not happen anytime soon, but Matejvelikonja seems to be putting alot of code in.

I think the biggest challenge would be having this command get access to the logfile. We are currently discussing how best to implement the logger in the first place, so that has to be decided first. Will the command directly pull the data from the log file? This would probably be a bad idea because it violates encapsulation. The optimal solution is to have the same object that logs the chat also have a method to return the data it has collected.

@matejvelikonja
Copy link
Collaborator

Logging should be one of the next top priorities.

But you have to take many considerations in it. Where will the log file be displayed. Bot cannot just output it to the channel stream because it would bother other users. A private chat would be possibly, but still a bit hard to get around. The best thing in my opinion would be an output to html and than exposed to browsers. There you could implement an easy search, interactive presentation of external links, etc.

But it's a long way to there and many other things have to be done first.

@super3
Copy link
Owner

super3 commented Jan 16, 2013

Yeah I was already assuming that the bot would send those in private chat. You also have to take into account any methods an irc server might have for flood control. Will it really allow you send 200 messages at once.

The best method is to run the IRC Bot on a webserver, and have it save HTML as you said. Then if you wanted to review the chat just visit the link that could be supplied in the chat topic.

@matejvelikonja
Copy link
Collaborator

What do you think about saving data? How should we save the chat log? Plain files? If we use it, than we have be careful with sizes. Large files could slow down system.

If we select database, the user is than forced to installed another dependency. And there are also lots of them. Maybe MongoDb would be appropriate for this kind of job. Saving simple, raw data on filesystem.

What do you guys think?

@super3
Copy link
Owner

super3 commented Jan 29, 2013

I mean lets walk before we run. We can just save the chat lots as plain txt file to start. If we want we can just use variations of that method to save chat logs in formats such as excel or JSON later.

We really don't have to worry about large files. My old script just separated the files by channel and by day, so even if thousands of people are chatting on a channel its not a big deal because its just text.

Since we are only displaying the chat logs at this point plain file will do, if we actually want to search it and stuff then we can worry about MongoDB, and that would be the better choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants