On Tue, 19 Nov 2019 09:51:00 +0000 Daniel Gultsch <dan...@gultsch.de> wrote:
> Am Sa., 16. Nov. 2019 um 17:48 Uhr schrieb Linus Jahn <l...@kaidan.im>: > > > I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster > > mechanism by a private PEP node. The basics are working now, but I'm > > not sure what's the best way to make presence sharing with the channel > > configurable. > > > > The roster mechanism allowed the client to disable presence sharing with > > the channel by setting subscription=none. How do you think it's best to > > do this with the PEP node? > > > > The PEP node could be made editable to the user (similar to the roster > > entry before). Then a custom rule for the server to only allow the > > 'share-presence' attribute to be modified would be needed. > > > > The other option I can think of is adding an IQ command to enable or > > disable presence sharing. Executing it would then trigger PEP > > notifications to be sent to the user. > > > > I think in both options this should already be configurable in the > > <client-join/> request, so a client does not need to send two requests > > when joining a channel with disabled presence sharing. > > > Thank you for bringing this back to the table. > > I don’t have strong feelings about this but my current thinking is > that it doesn’t have to be PEP. > I think we can all agree that a dedicated IQ command to flip the > send-presence flag would be less confusing and less error prone on the > server side. Continuing that line of thinking further I don’t see a > good reason why the channel list should be stored in PEP in the first > place. It's going to be read only for the client anyway; and on the > server side there is going to be a lot of special processing. Also the > PEP notification wire format has a lot of overhead. > Modeling the channel list after blocking command and roster (custom > IQs, first get will subscribe you automatically) might be more > straightforward for everyone. It also forces you into the "get entire > list on login" method (so you don’t forget). Furthermore a dedicated > mechanism might lift the "oh now I have to implement pubsub" burden > from server implementers, (Even though you might technically get > around with only implementing partial pubsub) > > cheers > Daniel I don't think that implementing PubSub is a real problem since PEP uses only a small subset of PubSub and PubSub is required for MIX anyway already. Also why should you use a custom protocol with the exact same concept for every PubSub-like feature. Wouldn't this basically mean to duplicate the roster or blocking command code in implementations for MIX. Of course it's more work to implement basic PubSub / PEP than just implementing a single IQ as for the blocking command, but once you've got PubSub many things are easier and can rely on that code, I think. Also the 'blocking command' way isn't so flexible. Ideally I would like to send one request to the server to receive all updates of all of my implicitly subscribed nodes after logging in. (I'm not entirely sure whether this is currently possible with PEP and MAM though?) The blocking command way would mean when logging in, the client needs to request all items of all subscribed 'nodes' (roster, blocking command, MIX, etc.) in single requests. Of course you could say let's do something like roster versioning for each of them to not produce unnecessary traffic, but doing this for every of them in a custom way doesn't seem to be correct. If you don't want to save the joined MIX channels in a way as a client, you can still request all channels of the node on each connect. About the traffic overhead of PubSub: I'd think that it's in the end lower than the overhead for requesting all joined channels on every login for the average user. The joined MIX channels probably won't change very frequently. I'm not sure if PEP was intended to have server-managed nodes, so maybe this could lead to additional work for existing server implementations. I agree that a dedicated IQ command for setting the send-presence flag is a good idea. I would like to hear some more comments though before I continue. Best regards, Linus _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
