mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject [vysper] XMPP components [WAS: Whole Server as Pubsub service]
Date Sun, 05 Jul 2009 09:49:29 GMT
Hi,

Earlier, we discussed, if PubSub should be addressable at
  "pubsub.vysper.org" instead of "pubsub@vysper.org", although the
server address is simply "vysper.org".

See below for the initial discussion:

Michael Jakl wrote:
<snip/>
> The InfoRequest returns the disco information for a particular node.
> The Pubsub module could be addressable by its own JID inside the
> server. "pubsub.vysper.org" or something.
>
<snip/>
>
> The question thus is, should I "enhance" the server with the pubsub
> service, or provide an additional entity within the server? I tend
> towards the first option, but I'm not quite sure. What would you
> suggest?

To allow this to happen, I changed DiscoInfoIQHandler.

All samples within pubsub spec go with "pubsub.vysper.org".
This is because, quoting from XEP-0060:

"... the examples throughout assume the existence of a separate pubsub
component..."

XMPP components are addressable via a "subdomain" of the server, for
example component "zappa" is addressable as "zappa.vysper.org". Pubsub
could be such a component, but in our case currently is a more internal
component (a Vysper 'module').

So I'd like to revert my change from r77422, allowing component domains
to go through regardless of any checks, or more concretely, removing

   to.getDomain().endsWith(serviceEntity.getDomain())

in DiscoInfoIQHandler and wait for a proper implementation of XEP-0114,
"Jabber Component Protocol" (plus maybe XEP-0225).

I've opened
  https://issues.apache.org/jira/browse/VYSPER-91
for this.

Any problems with the proposed change? Comments?

  Bernd


Mime
View raw message