[standards-jig] Re: LAST CALL: Service Discovery (JEP-0030)
jean-louis.seguineau at antepo.com
Thu Dec 5 19:26:51 UTC 2002
Having rarely been confronted with such an arrogant, possesive and short
sighted attitude, nor such a disgraceful one, I do not think it is worth
trying to convey any suggestion into that subject.
----- Original Message -----
> Message: 6
> Date: Thu, 5 Dec 2002 09:41:45 +1100
> From: Robert Norris <rob at cataclysm.cx>
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] Re: LAST CALL: Service Discovery (JEP-0030)
> Reply-To: standards-jig at jabber.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> > The JEP as it stands is totaly geared toward a client/server dialog. It
> > not totaly adequate in the case of component/server or server/server
> I disagree, simply because I have already implemented
> component-component discovery. Disco is great for this case - it took me
> around two hours to complete the implementation, and is very clean and
> > I would like to have a way to distinguish between various orginator
> > component, server) and have rdifferent eplies sent out for each
> > category. I don't know if this is putting adequately, but information
> > returned by disco could be 'public' and available to any requestor, and
> > may be 'private' or for some defined JID's eyes only.
> That should be handled by the entity responding to the disco request. If
> the requesting JID is not allowed to know about a particular entity,
> then the respondent should not mention it in the disco response.
> This kind of control is implementation specific, and is firmly outside
> the realm of discovery.
> > One certainly understand that a component might for example be
> > in knowing detail about the session manager running on the server,
> s a
> > client would not have to know about it. This was one of the deficiencies
> > earlier attempts at discovering services (agents, browse) and this is
> > corrected in the current disco proposal.
> A disco#items query only returns the JIDs that the queried entity knows
> about. This response has no information about the entity associated with
> the JID. For example, I can ask a server what components it knows about,
> and it will tell me, but I don't know anything about the type of those
> components without asking them.
> If a client isn't interested in information about a particular
> component, then it shouldn't ask. Its that simple.
> (Furthermore, from a clients perspective, the "server" and the "session
> manager" are one and the same. Perhaps a better example would be of some
> > Not having that kind of capability would lead to using different
> > for features discovery if one is programing for a client or for a
> > component/server. My take is that should be in the core disco rather
> > being handled by an extension. Doing so would make disco the real
> > 'extensible container' protocol it deserve to be.
> I'm not convinced. I haven't seen any shortcomings in disco yet, and it
> certainly fixes the problems that agents/browse had.
> Robert Norris GPG: 1024D/FC18E6C2
> Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> End of Standards-JIG Digest
More information about the Standards