Skip to content

Conversation

@BrennanConroy
Copy link
Member

Fixes #11258

Reusing HubOption to pass values to HubConnectionContext.

@BrennanConroy BrennanConroy added the area-signalr Includes: SignalR clients and servers label Jun 19, 2019
@BrennanConroy BrennanConroy added this to the 3.0.0-preview7 milestone Jun 19, 2019
@BrennanConroy BrennanConroy requested a review from davidfowl June 19, 2019 17:54
/// <param name="connectionContext">The underlying <see cref="ConnectionContext"/>.</param>
/// <param name="keepAliveInterval">The keep alive interval. If no messages are sent by the server in this interval, a Ping message will be sent.</param>
/// <param name="loggerFactory">The logger factory.</param>
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: Should we keep the 2 old constructors so this isn't a breaking change?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meh.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anurse Do we need to make an announcement?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure do!

/// <param name="streamBufferCapacity">The buffer size for client upload streams</param>
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval, int streamBufferCapacity)
/// <param name="hubOptions">The options to configure the connection.</param>
public HubConnectionContext(ConnectionContext connectionContext, ILoggerFactory loggerFactory, HubOptions hubOptions)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure we announce this breaking change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the options come before the logger? Then we could make the logger an optional param 😄

public HubConnectionContext(Microsoft.AspNetCore.Connections.ConnectionContext connectionContext, System.TimeSpan keepAliveInterval, Microsoft.Extensions.Logging.ILoggerFactory loggerFactory) { }
public HubConnectionContext(Microsoft.AspNetCore.Connections.ConnectionContext connectionContext, System.TimeSpan keepAliveInterval, Microsoft.Extensions.Logging.ILoggerFactory loggerFactory, System.TimeSpan clientTimeoutInterval) { }
public HubConnectionContext(Microsoft.AspNetCore.Connections.ConnectionContext connectionContext, System.TimeSpan keepAliveInterval, Microsoft.Extensions.Logging.ILoggerFactory loggerFactory, System.TimeSpan clientTimeoutInterval, int streamBufferCapacity) { }
public HubConnectionContext(Microsoft.AspNetCore.Connections.ConnectionContext connectionContext, Microsoft.AspNetCore.SignalR.HubOptions hubOptions, Microsoft.Extensions.Logging.ILoggerFactory loggerFactory) { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a standard order for parameters? I.e. do we always try to keep logger parameters last and options parameters second to last?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No idea

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this context be the hub options? Why isn't it its own context

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose HubOption because it contains the settings we want to pass to HubConnectionContext and I didn't want to make a new public type. We can change that if you'd like.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think we should have a HubConnectionContextOptions as this will start to break down the minute we need to pass something that isn't exactly an option.

@BrennanConroy
Copy link
Member Author

@aspnet-hello
Copy link

This comment was made automatically. If there is a problem contact [email protected].

I've triaged the above build. I've created/commented on the following issue(s)
https://github.com/aspnet/AspNetCore-Internal/issues/2293

@BrennanConroy BrennanConroy merged commit e8181ae into master Jun 20, 2019
@ghost ghost deleted the brecon/hubconnectioncontext branch June 20, 2019 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-signalr Includes: SignalR clients and servers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[API Review]: HubConnectionContext should take an options object

7 participants