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

nick nick at jabberstudio.org
Fri Dec 6 04:51:16 UTC 2002


<jest type=tongue_in_cheek>
    pot calling the tea kettle black?
</jest>

Jean-Louis Seguineau/EXC/TEC wrote:

>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
>>
>>    
>>
>
>_______________________________________________
>Standards-JIG mailing list
>Standards-JIG at jabber.org
>http://mailman.jabber.org/listinfo/standards-jig
>  
>




More information about the Standards mailing list