[standards-jig] Re: LAST CALL: Service Discovery (JEP-0030)

Jean-Louis Seguineau/EXC/TEC 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
>
>
> --jL2BoiuKMElzg3CS
> 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
is
> > not totaly adequate in the case of component/server or server/server
dial=
> og.
>
> 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
> modular.
>
> > I would like to have a way to distinguish between various orginator
(clie=
> nt,
> > component, server) and have rdifferent eplies sent out  for each
requestor
> > category. I don't know if this is putting adequately, but information
> > returned by disco could be 'public' and available to any requestor, and
s=
> ome
> > 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
interrested
> > in knowing detail about the session manager running on the server,
wherea=
> s a
> > client would not have to know about it. This was one of the deficiencies
=
> of
> > earlier attempts at discovering services (agents, browse) and this is
not
> > 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
> use).
>
> > Not having that kind of capability would lead to using different
protocol
> > 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
than
> > 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.
>
> Rob.
>
> --=20
> Robert Norris                                       GPG: 1024D/FC18E6C2
> Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
>
> --jL2BoiuKMElzg3CS
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQE97oSpWb13Z/wY5sIRApLJAJ9l/HbWzQYUgpXOBGVbfyNa0qr/wACfbx+E
> Mm7Gf/WilSuZYEdkDXaSbAw=
> =OGUO
> -----END PGP SIGNATURE-----
>
> --jL2BoiuKMElzg3CS--
>
>
> --__--__--
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
>
>
> End of Standards-JIG Digest
>




More information about the Standards mailing list