channel metadata changes

[imaginator]

(originally mentioned in Issue 24

The proposal is to move this to a node (/user/:channelID/metadata).

Benefits:

• ensure updates are pushed as edits happen

• it should be delivered when you ask for that users channels rather than having to add

  AFAIK, it's just a matter of dev-time to get this added on the server. Anyone else have some good ideas about this?

[denisw]

Disadvantage: Reinvention of existing Pub-Sub functionality.

http://xmpp.org/extensions/xep-0060.html#owner-configure-process-notify

[imaginator]

To be clear, this is about how we streamline the retrieval of channel Names
and Description data and speed that up.

On 2 October 2012 14:05, Denis Washington [email protected] wrote:

Disadvantage: Reinvention of existing Pub-Sub functionality.

http://xmpp.org/extensions/xep-0060.html#owner-configure-process-notify

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/89#issuecomment-9068531.

Simon Tennant | buddycloud.com | +49 17 8545 0880

[Schnouki]

I agree with Denis. It's already annoying (IMO) to have /posts, /status, and /subscriptions, with possibly different access models, so I don't think adding yet another node would solve this.

(I think we could just get rid /status (replace it with buddycloud#status in the channel config) and /subscriptions (use standard PubSub requests + RSM + MAM + a custom "affiliation" attribute to make things easier), but these would be huge incompatible protocol changes, so we need to think more carefully about this. Maybe at the next hackathon? :)

In my opinion, if you want to speed things up in the web client, don't retrieve the followers/following lists every time you load a channel. Or at least don't display them, because the avatars take forever to load. The best would be to do like Twitter: display the number of following/followers, and let the user click on that to actually load the list. We could even add some new (read-only, dynamic) entries in the channel config (buddycloud#subscriptions, buddycloud#subscribers, buddycloud#moderators, etc.) to have these numbers without additional requests. What do you think?

[imaginator]

Agreed. Let's bring bring up protocol changes at the next hackathon (issue is tagged as long-term).

I think this also plays into the fact that we have lots of nodes that also have different permissions. Would be nice to unify that too.

So, some whiteboard time and another hackathon... I'll create a doodle.

S.

[imaginator]

The design of the webclient is for the info tab (RHS column) to be closed by default. That alone will reduce the number of hits for subscriber data and the hammering of the media server for avatar data.