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

Feature request: conversation & event logging. #201

Open
alxpettit opened this Issue Sep 3, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@alxpettit
Copy link

alxpettit commented Sep 3, 2018

I have started using Syncplay for study sessions with my friend. As we study, we chat back and forth and occasionally come to insights over the chat interface, which are useful to record for future grepping.

Unfortunately, the only way for us to save them currently is by hand. Would it be possible to add an optional dead-simple logging feature? I'm thinking something to the effect of storing logs as plaintext files under the existing ~/.config/Syncplay/logs, or ~/.local/share/Syncplay/logs if y'all prefer to put it in a more conventional place. The logs could simply be files created on a per-session basis, a la Pidgin (for instance, 2018-08-22.145910-0400EDT.txt for a session created at that time, then following that a new file uniquely based on the time of the next session, etc etc.)...

Or they could all be dumped to one continuously updated text file, if one doesn't mind the risk of forming very large files.

@alxpettit

This comment has been minimized.

Copy link
Author

alxpettit commented Sep 3, 2018

Oh, yeah, and Windows exists too. I forgot Windows exists. I suppose it could be put under %appdata% or something for the Windows people. :P

What does everyone think?

@Et0h

This comment has been minimized.

Copy link
Contributor

Et0h commented Sep 30, 2018

Yes it would be possible. I'd be interested in hearing what people think with respect to:

  • How it should be enabled/disabled
  • What would be included in the log
  • What a log should look like (i.e. provide an indicative example)
  • What the filenames should look like - would it be linked to the room, file, date, server, etc?
@alxpettit

This comment has been minimized.

Copy link
Author

alxpettit commented Feb 19, 2019

Enabling/disabling should be done in server config as with any other feature. Logging should range from sparse to verbose, optimally.

For instance, in my use case, I'd just want a plaintext log of who said what. In the case of someone running a large server and troubleshooting a problem, they might want a log to tell them in detail what handshake happened and what JSON strings changed hands during the error.

In the case of someone running a private server that was subject to a hacking attempt, they might like to have a log that they can point fail2ban at so that they can automatically blacklist the IP. Or they might just detect it manually.

Ideally, all these use cases should be satisfied by the same code, so as to minimize the need for future refactoring. Logging should be minimal by default, to protect privacy -- perhaps with logging connections and disconnections like IRC servers typically do by default, but not logging everything that was said.

Since we live in the SystemD era, logging to STDERR is going to be fine for a lot of people, including me -- but some people might like logging to files to be a feature.

Since there are a lot of events to log, and I also wanted to create some sort of event hook system, I think an optimal way to handle these two things would be with a single function -- something like:

report_event("Sentence to help contextualize what's going on in log entry", contextual_data, log_level)

Which would simultaneously go on to log the event and optimally trigger external code for custom user scripts. Furthermore, log_level would just be a simple int with associated codes ranging from DEBUG (show everything) to NONE.

Hopefully server administrators should know their way around grep and the like, so logging different events to different files seems like overkill to me. I would just put it all in one file -- the location of which can be decided by the end user, but I imagine a lot of people (including myself) would just do something like --log-destination - to log to STDERR, and then just run the thing under systemd. To accommodate that, printing out dates on each log entry should be an optional feature. To keep things simple, STDERR logging should probably be default, with the option to override the target file object to an actual physical file of the user's choice.

I am aware that this would add quite a lot of additional configuration options... but on a side note I've been thinking about making a pull request to add a server configuration file -- so maybe I should take care of that first? Here are some config options we'll probably need:

  • --log-destination: where to put the log file. Defaults to - for STDERR.
  • --log-level: int value or associated keyword indicating how much to log. Set to 0 to disable logging entirely.

So... let me know what everyone thinks, and if any more input on my part is needed! :)

@Uriziel

This comment has been minimized.

Copy link
Contributor

Uriziel commented Mar 6, 2019

I think logging feature is cool for client side.

For the servers though, I guess it would go against Syncplay's: "no user data stored" policy.
In my opinion servers should still avoid the logging feature altogether. Also it would add uncanny amount amount of work.

For the clients, I think logging what's appearing in the GUI should be enough, can't see any reasons for log-levels.
For the destination, if it's not a single file log, then Syncplay would need to create a folder for itself to store all the files (in home/%appdata%).

Cheers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.