-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Ssh #60
Ssh #60
Conversation
|
||
namespace TeamSpeak3QueryApi.Net | ||
namespace TeamSpeak3QueryApi.Net.Query |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of the query client and belongs to the TeamSpeak3QueryApi.Net
namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cause a query command is still part of the query client. So it should stay in the query folder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The namespcae layout is as follows:
namespace TeamSpeak3QueryApi.Net
: Everything related to the Query protocol itself (that also the regular TS client uses)
namespace TeamSpeak3QueryApi.Net.Specialised
: While the name Specialised
is disputable, this contains the concrete server query implementation.
One core principle is that the child namespaces should only rely on the parent namespaces (not some sibling namespace) if possible. Introducing a Query
namespace would break this semantic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean I should change the class name QueryClient to just Client cause it´s in the namespace Query? (For example)
Thanks for the PR! |
All changes they have a like will be changed until next week. I am this week not @home. I know this is a big pr but this isn't a final version for sure. I just want to create a final version with ssh support for everyone. I am sure this brench need some investigation. |
So I´am done. Let me know if something else should be fixed or changed. |
public interface IProtocol | ||
{ | ||
Task<CancellationTokenSource> ConnectAsync(); | ||
CancellationTokenSource Connect(string username, string password); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A CancellationToken
should be returned, not a CancellationTokenSource
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? This function is not changed. You also returned the CancellationTokenSource
. It´s needed for the processingloop. Did I miss something?
@@ -31,128 +30,52 @@ public class QueryClient : IDisposable | |||
|
|||
/// <summary>Gets the remote host of the Query API client.</summary> | |||
/// <returns>The remote host of the Query API client.</returns> | |||
public string Host { get; } | |||
public string Host { get; internal set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why internal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don´t want that somebody outside this class could change the host. But the Ssh or Telnet client need to set the host and for that it must get more access.
|
||
namespace TeamSpeak3QueryApi.Net | ||
namespace TeamSpeak3QueryApi.Net.Query |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The namespcae layout is as follows:
namespace TeamSpeak3QueryApi.Net
: Everything related to the Query protocol itself (that also the regular TS client uses)
namespace TeamSpeak3QueryApi.Net.Specialised
: While the name Specialised
is disputable, this contains the concrete server query implementation.
One core principle is that the child namespaces should only rely on the parent namespaces (not some sibling namespace) if possible. Introducing a Query
namespace would break this semantic.
@@ -15,6 +15,7 @@ | |||
using TeamSpeak3QueryApi.Net.Query.Parameters; | |||
using TeamSpeak3QueryApi.Net.Query.Responses; | |||
using TeamSpeak3QueryApi.Net.Query.Enums; | |||
using TeamSpeak3QueryApi.Net.Query.Protocols; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I think namespaces like Enums
etc. might be good for applications, I don't think that a library should use that pattern. For example System.Windows.Forms
doesn't have something like Controls
, Components
etc. either. This way, the core principle mentioned above is easier to follow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a matter of taste. I would like to stay like this. It´s for me better readable if we stay in folder and not change the classnames. Or we could change the classnames and stay also in the folders?
Is still interested in this pr, if not I would release it as a new nuget package. |
I'm still interested in merging this! :) Currently, I'm short on spare time for this project. Maybe we can settle this down this weekend. |
A lot of Bugfixes like in pull request #57. But now it's also possible to create ssh connections and Telnet connections. See example here #58
I would like to prefer this as new mayor version 2.0. So we could have 1 big break and then we don't need to talk about this anymore 👍