Matthew A. Miller wrote:

The solutions given up to this point are valid if only users on your
server will be accessing the component.  If the component is to be
accessible to users outside of your server, the above is what needs to
be done.
Imho the number of components attached to a server is due encrease a lot in the near future. Jabber may be seen as an alternative to webservices and as a developer I wouln't like like to set up a FQDN for each implemented service. What about giving the option to use resources for component ids? Something as jabberserver.mydomain/mycomponent, in this way they can't be confused with normal clients

Alternatively, you *could* write your component to connect as a client
(to get a JID such as "component@server").  This means your component is
really a client though, with all the benefits, restrictions, and
overhead that entails.
At present this may be the solution for my needs: a server just bots implemented as clients, with special karma settings for c2s communications, almost equal to s2s ones (I can set up all the servers I want, but living in a big organization is not easy to have all the FQDNs I'd like)

--
Fabio Forno - PhD Student
Politecnico di Torino - Dip. Automatica ed Informatica
C.so Duca degli Abruzzi 24 - 10129 Torino (Italy)
Phone: +39 011 546 7137 - JabberId: [EMAIL PROTECTED]

_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev


Reply via email to