[Council] VOTE: Service Discovery (JEP-0030)

David Waite mass at akuma.org
Wed Apr 9 14:07:44 CDT 2003


Peter Saint-Andre wrote:

>It's time to vote on Service Discovery (JEP-0030). This is a standards 
>track JEP, so your +1 vote means you approve of advancing this JEP to 
>Draft. If you vote -1, please provide a reason.
>
>http://www.jabber.org/jeps/jep-0030.html
>
>Peter
>
+1, but not without comments :-)

- It seems that the ability to delegate feature support to another JID 
would be nice; for example, I might want searches against my muc 
implementation to go against a database, which provides history 
searching as well.  An alternate implementation could redirect on search 
requests, but of course redirection of this sort is not standardized. I 
figure if this i needed, it will come up during implementation. It could 
be made as an extension of service discovery as well.
- I know I've brought this up before, but I still think it would be nice 
if you could a query of both features and (child) items in one fell 
swoop with a single iq. It adds no functionality, but it prevents one 
round-trip and a couple hundred bytes of traffic every time you connect 
to your server.
- I'm still frustrated that the JANA category types and feature seeding 
is still in there. Knowing that a node provides 'game/chess' does not 
help the fact that we have no corresponding 'game/chess' protocol to 
work with. The "presence-invisible" feature is a standards-track 
proposal for addition of an informational JEP feature (which isn't even 
defined in that informational JEP) - there is absolutely no definition 
of how to discover this feature or what its 'presence' implies (although 
it is feasable to guess). These categories types and features should be 
standardized by appropriate JEPs or at least developer requests; then 
the meaning of them can be properly defined.

I'm not going to hold up this JEP up because of the seeding (partially 
because I've held it up enough - stpeter I _swear_ I sent this email 
before), but the whole point of JANA is to have these definitions 
centralized so that we can properly track the list in this JEP. Tracking 
the definition of  a 'directory/room' to a single line in the 
service-disovery JEP rather than MUC or some other JEP that describes 
the expected features corresponding to a 'directory/room' limits the 
usefulness of that centralized JANA list.

-David Waite




More information about the Council mailing list