So, um, yes, feedback on this collection of specs, which together
make up 90% of Webfinger, is most welcomed.
-John
[1] Yes, I am committing heresy by conflating resources and
representations here; please insert standard argument back and forth
on the subject if you feel like doing so.
On Mon, Dec 28, 2009 at 10:39 AM, Joe Gregorio <joe@xxxxxxxxxxxxxx>
wrote:
On Mon, Dec 28, 2009 at 1:16 PM, DeWitt Clinton <dewitt@xxxxxxxx>
wrote:
> The one on my mind lately has been Webfinger
> (http://code.google.com/p/webfinger/). The standard content type
for
> /.well-known/host-meta/ queries and webfinger queries is XRD
> (http://www.oasis-open.org/committees/download.php/35274/xrd-1.0-wd10.html
).
The value of a protocol goes up with the ease of implementation, and
adding in options almost always makes an implementation harder.
In addition I don't understand the use of XRD, nor of using any XML
format
for webfinger. To put this in context, if I were to start working on
AtomPub
today, I would use JSON (for everything I couldn't figure out how to
stuff into
headers). Where exactly is webfinger, that is, is it worth it for me
to
give feedback at this time?
> However, there seems to be both interest and value in returning
these
> documents in other formats -- in particular JSON and HTML, though
Atom
> entries are also a strong possibility if we can align XRD's link
element a
> bit better -- hence the desire to perform some sort of content
negotiation.
> This can be implemented via a URL-modifying switch (i.e., a
'format' flag),
> such as I do at http://webfingerclient-dclinton.appspot.com/, but
there's no
> reason the server shouldn't be able to infer the client's desired
media type
> given enough hints in the request.
> Also, given the ever-increasing popularity of JSON as an
alternative to XML,
> I suspect that many Atom-based servers would also like to offer a
negotiated
> option of a JSON return format. I know I'd like that for
syndicated search
> results, for example.
IF a JSON based alternative to AtomPub were to be developed, I'm not
sure
how conneg would help. How would having a different URI for the
equivalent
of the service document hurt adoption? (I'm presuming it would be
AtomPub-like
and have a service document or a collection document and that you
just follow
links from there, at which point the URIs could be different for
Atom and JSON
based representations, so conneg would only be needed on the the
very first resource you touched.)
Thanks,
-joe
> Sorry, this has strayed off topic -- I'll pick up this thread
elsewhere if
> needed.
> -DeWitt