"I always find this annotation as misleading. It tightens the current
habbit of tightly binding services with servers."

Yeah, that's the main thing about it that bothered me. The standards
seem to encourage the use of sub-domains for naming services. The
examples in XEP-0030 place each service on a sub-domain. I wonder if the
standard could be updated to add some way of addressing services and
components that doesn't require extra domains or sub-domains?
--- Begin Message ---
Dnia 2011-01-31, pon o godzinie 23:23 -0800, Keith Jay Gillis pisze: 
> A host that offers text-based conferencing capabilities; often but not
> necessarily a sub-domain of a Jabber server (e.g.,
> conference.jabber.org).

I always find this annotation as misleading.
It tightens the current habbit of tightly binding services with servers.

> Is it possible to use mu-conference with jabberd2 without putting
> mu-conference on a sub-domain?

It's perfectly possible to run a conference service on its own domain.
It's domain name is nothing special and does not have to be a subdomain
of jabber server.

ie. I run my conference service and transports on a completely separate
host, with only router and s2s components companion. Router to handle
component protocol connections, and s2s to give the components network

> I had hoped that a chat service and XMPP server could both have the same
> domain.

But... If you want to share a single domain between different
components, ie. a chat component and a session manager - it's not
possible with jabberd2. This would require an application protocol level
stanza routing which is not supported. In other words - router would
have to inspect contents of every packet and decide which component the
packet should be routed to. It is possible to do, but it's complicated
and inefficient.

> I see from XEP-0045 that a chat service needs to have a JID to direct
> room queries to. Could it have a JID of confere...@example.com of
> example.com/conference instead of conference.example.com?

Not possible. MUC encodes nicknames as resources. You need to run it on
separate domain.

> Also, are there plans to make the jabberd2 component protocol an
> official extension?

Kind of...
Some elements of jabberd2 component protocol are on it's way to
standardization. See XEP-0225

The rest is jabberd2 internal design specific and may not be that useful
for other implementations.

Tomasz Sterna
Instant Messaging Consultant : Open Source Developer
http://tomasz.sterna.tv/  http://www.xiaoka.com/

To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com

--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to