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

XEP-0030: Service Discovery #28

Closed
SamWhited opened this issue Feb 26, 2020 · 1 comment
Closed

XEP-0030: Service Discovery #28

SamWhited opened this issue Feb 26, 2020 · 1 comment
Labels
Milestone

Comments

@SamWhited
Copy link
Member

@SamWhited SamWhited commented Feb 26, 2020

XEP-0030: Service Discovery should be implemented in a new disco package and be integrated with the mux package so that a multiplexer can respond to disco requests using the handlers that have already been registered.

Design doc: https://mellium.im/design/28_disco

@SamWhited SamWhited added this to the v0.18.0 milestone Nov 16, 2020
@SamWhited SamWhited removed this from the v0.18.0 milestone Jan 15, 2021
@SamWhited SamWhited added this to the v0.19.0 milestone Jan 15, 2021
MelliumBot pushed a commit that referenced this issue Feb 15, 2021
See #28

Signed-off-by: Sam Whited <sam@samwhited.com>
MelliumBot pushed a commit that referenced this issue Feb 15, 2021
See #28

Signed-off-by: Sam Whited <sam@samwhited.com>
MelliumBot pushed a commit that referenced this issue Feb 20, 2021
See #28

Signed-off-by: Sam Whited <sam@samwhited.com>
@SamWhited SamWhited removed this from the v0.19.0 milestone May 2, 2021
@SamWhited SamWhited added this to the v0.20.0 milestone May 2, 2021
@SamWhited
Copy link
Member Author

@SamWhited SamWhited commented Jul 9, 2021

I had an idea today that may supersede this design doc. Thinking about the way we recently implemented muc I thought we might start following the design principal "handle behavior, not state". If the user is handling state it lets them be maximally flexible and scale to their own needs without having to rewrite entire modules. Eg in a muc we don't actually keep track of all the MUCs we've joined and all the users in those MUCs, we leave that to the application or a higher-level library to implement.
We can do the same here. Instead of a registry that we add all our disco features too, what if we just provide an interface for figuring out what features are supported by a handler? Then we don't have to store a registry and process it.

In our specific case mux is the higher level library, but since the handlers don't have access to all the other handlers we would implement disco as a middleware instead, ie. in the disco package we'd have something like:

// Handle returns a new handler that wraps a mux.ServeMux and responds to disco requests.
func Handle(m *mux.ServeMux) xmpp.Handler { … }

Loading

MelliumBot pushed a commit that referenced this issue Aug 10, 2021
This finally closes the long standing need for service discovery by
implementing the new design doc from https://mellium.im/design/28_disco!

Fixes #28

Signed-off-by: Sam Whited <sam@samwhited.com>
MelliumBot pushed a commit that referenced this issue Aug 10, 2021
This finally closes the long standing need for service discovery by
implementing the new design doc from https://mellium.im/design/28_disco!

Fixes #28

Signed-off-by: Sam Whited <sam@samwhited.com>
MelliumBot pushed a commit that referenced this issue Aug 10, 2021
This finally closes the long standing need for service discovery by
implementing the new design doc from https://mellium.im/design/28_disco!

Fixes #28

Signed-off-by: Sam Whited <sam@samwhited.com>
MelliumBot pushed a commit that referenced this issue Aug 11, 2021
This finally closes the long standing need for service discovery by
implementing the new design doc from https://mellium.im/design/28_disco!

Fixes #28

Signed-off-by: Sam Whited <sam@samwhited.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant