XEP-0030: Service Discovery #28

New Issue

Closed

opened 2020-02-26 23:53:24 +00:00 by SamWhited · 1 comment

SamWhited commented

2020-02-26 23:53:24 +00:00

Owner

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

[XEP-0030: Service Discovery][XEP-0030] 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. [XEP-0030]: https://xmpp.org/extensions/xep-0030.html [`mux`]: https://pkg.go.dev/mellium.im/xmpp/mux **Design doc:** https://mellium.im/design/28_disco

SamWhited commented

2021-07-09 13:15:09 +00:00

Author

Owner

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 { … }

I had an idea today that may supersede this design doc. Thinking about the way we recently implemented [`muc`](https://pkg.go.dev/mellium.im/xmpp/muc@main) 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: ```go // Handle returns a new handler that wraps a mux.ServeMux and responds to disco requests. func Handle(m *mux.ServeMux) xmpp.Handler { … } ```