Re: service description discovery

Hi,

On 11 Sep 2009, at 03:31, Gregory Williams wrote:

> I'm trying to sort out where we left the discussion on service  
> description discovery. As best I can tell, there are (roughly) four  
> remaining options that we've discussed:
>
> option 1: link header that points to a URI where the service  
> description can be downloaded (2,9,0)
> option 2 - use the HTTP OPTION verb on the endpoint URI (8,4,1)
> option 7 - standard query, using content negotiation to get the  
> service description (4,1,4)
> option 8 - new protocol operation (no strawpoll results yet)
>
> The numbers in parentheses represent the strawpoll votes for (-1, 0,  
> +1), respectively.
>
> I don't believe we ever got a vote on option 8. Between the other 3,  
> option 7 had the most +1 votes, as well as the highest +1:-1 ratio.

You mean option 2 ?

> Having said that, I think we also left off on the August 18th  
> telecon without discussing the option 7' variant with RDFa.
>
> So, I guess I'd like to hear what people think of option 8 and the  
> RDFa variant(s) of option 7. Steve has previously discussed an  
> implementation problem when using option 8 and reverse proxies, and  
> there was some worry about the lack of widespread support for RDFa.  
> Anything else?

It seems to me that the issues raised by Steve with option 8 happen is  
really particular cases - any idea on how often that reverse proxy  
setting happens ?

In addition, all others from the list (besides option 2 ?) also got  
issues:

option 1: link header implies that there is an HTML page at the  
endpoint URL which is not always the case
option 2: don't see any particular issue here, but I'm wondering how  
easy is that, from a usual Web browser, to send that HTTP OPTION verb
option 7: proper conneg is a pain to specify and implement
option 7' (RDFa): pb with (non-X)HTML + implies there is a webpage at  
the endpoint URL.

So, shouldn't we simply focus on the one that has no issue, if any.
And it not, consider the ones with the less problematic issues (to me,  
would be 8 in that case).

Best,

Alex.


>
> thanks,
> .greg
>
>

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Monday, 14 September 2009 09:21:42 UTC