[Foundation] Motion to propose JEP-0030 (Service Discovery) to council

[Ulrich Staudinger]

Ok. I agree with Edrin and vote against disco. My questions and reasons
are:

- Why throw away code (of existing clients) instead of enhancing
existing code?
- Why not making iq:browse better/improving the jep?
- When improving iq:browse, existing code will stay compatible, why
throw away this superiority of iq:browse?
- Why not merge disco into browse? 


Commenting to pgm's mail:

> 1) A single result set gives you capabilities (supported namespaces) as well
> as a list of child entities and THOSE supported namespaces.

I agree with you. This is an issue which should be fixed in iq:browse,
because this really can blow up a response.

> 2) It is limited by the <ns> element, and is not generic enough.

Agreed, DTD should be opened.

> 3) A parent node must either "know" or cache all of the browse info for all
> of it's children (since child nodes are reported back w/ the parent). This
> means that a parent node must always know all of the possible information
> about all children, or be able to cache that info so it can report back.

Same as 1). The parent node should just respond with a list of children
and the namespaces/elements whatever the parent node itself supports. 


One of the main things i really miss in iq:browse is real browsing. An
entity should be allowed to respond to a browse request with whatever it
wants to respond with. 

A personal critic on disco is: the namespace is stitched. I *personally*
don't like stitching strings together, i really prefer consistent
namespace(s). 

regards,
ulrich