#dev 2016-09-19

2016-09-19 UTC
KevinMarks, tantek, AngeloGladding, KevinMarks_ and sknebel joined the channel
#
tantek.com edited /read (+786) "my previous chapter example, provide e.g. for read chapter text, ok to use ch. to abbr" (view diff)
#
@kevinmarks @SaraSoueidan @stevefaulkner @brucel @heydonworks it makes more sense with a webmention when you are bringing in comments from another site (twitter.com/_/status/777791811439910913)
tantek and cweiske joined the channel
#
cweiske .
#
Loqi cweiske: ben_thatmustbeme left you a message 3 days, 12 hours ago: yes I am building a new MP client
#
Loqi cweiske: ben_thatmustbeme left you a message 2 days, 19 hours ago: wonder if we should do a similar implementation status list for clients
tantek, singpolyma, loicm_ and KevinMarks joined the channel
#
adactio.com edited /events/2016-09-21-homebrew-website-club (+6) "/* Where */" (view diff)
#
tantek.com edited /timeline (+1159) "IndieWebCamps in 2015-2016" (view diff)
singpolyma and cweiske joined the channel
#
cweiske.de edited /Micropub/Servers (+32) "/* Implementation status */ url only file upload" (view diff)
tantek joined the channel
#
@entropicstudio Wouldn’t it be great it there was a standardized way to notify other websites when you link to them? https://premium.wpmudev.org/blog/trackbacks-pingbacks-webmentions/ (twitter.com/_/status/777907834503782400)
#
@entropicstudio Wouldn’t it be great it there was a standardized way to notify other websites when you link to them? https://premium.wpmudev.org/blog/trackbacks-pingbacks-webmentions/ (twitter.com/_/status/777907721605615616)
#
cweiske i wonder why wordpress doesn't follow the psr style rules
#
cweiske https://core.trac.wordpress.org/ticket/23357
#
cweiske "will not happen, too far from our coding standards"
#
cweiske.de edited /Micropub (+268) "/* Adding Files */ curl example" (view diff)
#
cweiske minimal micropub media endpoint in PHP: http://p.cweiske.de/363
#
cweiske.de edited /Micropub/Servers (+79) "minimal micropub media endpoint in PHP" (view diff)
#
cweiske.de edited /Micropub/Servers (+170) "/* Implementation status */ server "configuration" implementation status" (view diff)
#
cweiske voxpelli, I've had enough API situations in which validating the returned content type quickly told me that either I made an error, or the API sent something strange to my request. reduced debugging time
#
voxpelli cweiske: my experience instead says that trying to return the same format no matter which situation and then inspecting the data itself and/or response code is preferable
#
voxpelli Especially considering the crazily complicated specs of accept headers etc
#
cweiske if everyone thought that way, then the content-type header would not exist
#
cweiske since you can always inspect the content. hah.
#
voxpelli Content-types to me are to control whether response should be eg. HTML, xml or json – not any more than that
#
voxpelli You can only inspect the content if you get an instruction on how you can expect to be able to inspect it
#
voxpelli But true, many clients ignore content types and simply parse the response in different ways until a parser returns a non-error result of the parsing
#
cweiske magic bytes and heuristics always allow you to inspect anything
#
voxpelli Can you show some pre-existing work and some arguments on why error-specific content types would add anything and make things better in any way?
#
cweiske "reduces debugging time" is my argument, and I only used it in commercial closed-source projects.
#
voxpelli The downside of them are that any clients that expect a json response to have the content type "application/json" will fail to parse the response
#
voxpelli cweiske: so far I only see an argument that it reduces _your_ debugging time to be fair. It would probably increase mine because I would totally not expect it
#
voxpelli (Also, your suggestion is by the way wrong as I can see, the proper mime-type would be application/json+modifier)
#
cweiske no
#
cweiske it's correct
#
voxpelli Compare to eg text/xml+atom
#
cweiske it's application/atom+xml
#
cweiske RFC 4287
#
voxpelli Right, um, well – that in itself is a pretty good argument why mime-types are crazily confusing and should just be left as simple as possible ;)
#
cweiske see http://www.iana.org/assignments/media-types/media-types.xhtml
#
cweiske search for "+xml"
#
cweiske and "+json"
#
cweiske the argument is about micropub, which itself is much more crazily confusing than a plain string with a / and a + in it
#
voxpelli The simplest of things can be the most confusing ones
#
cweiske oh, we're at that level now. good night
#
voxpelli Just try to parse an Accept header and tell whether you found it to be easier or harder than implementing an Micropub endpoint for example
#
Loqi night
#
voxpelli sighs
#
voxpelli I'm not trying to make a fight or something – I honestly think that content-types can get very confusing and hard
#
voxpelli I mean: People generally can't even get HTTP codes and HTTP methods right and that's just three numbers and four methods
#
bear IMO we should leave alone anything that touches accept headers and mime-types and just say this: all indieweb traffic is done using json
#
bear then the headers and mime-types are left to the web server, the browser and the language tools
gRegorLove joined the channel
#
Zegnat What even started that discussion? I just see cweiske start off about APIs to you, voxpelli?
#
voxpelli Zegnat: I watch the Micropub repo on GitHub and saw his comment there and felt the need to comment on it
#
aaronpk um, i'd rather not mess with inventing new content types
#
voxpelli aaronpk: btw, regarding Micropub, is there a way for an endpoint to return an error that is going to be shown to the user?
#
voxpelli So the endpoint can enforce additional constraints that will be communicated clearly to the client when they are violated
#
aaronpk not currently
#
voxpelli s/client/user/
#
aaronpk do you have an example of what you're trying to do?
#
voxpelli aaronpk: the slug issue was a case where you might want to do it
#
voxpelli Or some other case where eg a tag is including some non-acceptable chars or something
#
voxpelli Any kind of validation error that may have to be enforced by the endpoint
#
aaronpk interesting
#
voxpelli If one just can deliver such a message then all suck kinds of cases becomes a non-issue from a spec point of view
#
voxpelli I guess I could show such a message if I fail to communicate to GitHub or fail to translate it to a Jekyll document
#
aaronpk typically the error messages that APIs return are not user-centric, and more often than not just confuse the user rather than help them. it's an interesting idea to have a special property to explicitly return a user-level error message, especially since with Micropub, we have lots of different server implementations that have various restrictions outside of what the spec requires
#
voxpelli Exactly what I'm thinking :)
#
bear i've always been a fan of { "result": { "code": 5XX, "message": "you did something wrong", "text": "here is a text version of why I decided to not let you do this..." } }
#
aaronpk i've been following the oauth2 error response format of {"error":"something_wrong", "error_description":"Message to the developer"}
#
bear *nods* that works also if the transport is HTTP
#
aaronpk any other thoughts on this? https://github.com/w3c/Micropub/issues/54
#
bear I added a thought
#
aaronpk ?
#
aaronpk computers are hard
#
bear very
#
bear especially when you blend services created by web front-end types that are then implemented by server back-end types :)
#
bear the js-ification of services as I like to say in private
#
aaronpk voxpelli: while you're here, check out the change I made about your comment from a while ago: https://github.com/w3c/Micropub/issues/33
#
voxpelli aaronpk: I'm just about to head to sleep, but general thought is that looks good, only thing maybe lacking is how to add a non-experimental property – if eg another spec wants to extend Micropub
#
aaronpk i guess that would be opening a new issue
AngeloGladding, KevinMarks, sknebel, tantek and KevinMarks_ joined the channel
#
martymcgui.re edited /events/2016-09-21-homebrew-website-club (+503) "/* Where */ add HWC Baltimore meetup for 9/21" (view diff)
#
martymcgui.re edited /Homebrew_Website_Club (+250) "/* Getting Started or Need Restarting */ Add HWC Baltimore" (view diff)
#
martymcgui.re edited /events/2016-09-21-homebrew-website-club (+236) "/* RSVP */ add Baltimore to RSVP section." (view diff)