/irc-logs / freenode / #whatwg / 2012-09-16 / end

Options:

  1. # Session Start: Sun Sep 16 00:00:00 2012
  2. # Session Ident: #whatwg
  3. # [00:01] * Joins: mattgifford (~mattgiffo@108.161.20.199)
  4. # [00:02] * Quits: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi) (Ping timeout: 272 seconds)
  5. # [00:04] * Joins: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi)
  6. # [00:05] * Quits: Martin_L (~Martin_L@213-65-125-129-no120.tbcn.telia.com) (Remote host closed the connection)
  7. # [00:05] * Quits: MikeSmith (~MikeSmith@manaslu.utelisys.net) (Read error: Connection reset by peer)
  8. # [00:05] * Joins: MikeSmith (~MikeSmith@manaslu.utelisys.net)
  9. # [00:11] * Joins: brainproxy (~brainprox@pdpc/supporter/gold/brainproxy)
  10. # [00:12] <brainproxy> will this patch to the w3c's html5 spec re: link relations be incorporated into the whatwg's living standard?
  11. # [00:12] <brainproxy> https://github.com/w3c/html/commit/954203e085e601122a2df38207bfdd6d852a0963
  12. # [00:13] <Hixie> no
  13. # [00:13] <Hixie> (it's pointless)
  14. # [00:14] <Hixie> (it's so trivial to register a link type that there's really no reason to use a url, and urls wouldn't work right anyway since the rel="" field is case-insensitive and doesn't do url processing so really they'd just be opaque strings)
  15. # [00:14] <Hixie> (if we wanted to support a non-registered proprietary value space here, we'd likely use java-style reverse-dns names, not urls)
  16. # [00:15] <brainproxy> what if I'm developing an "semantic profile" based API, like Amundsen's ALPS, and I don't want to necessarily register links rels, but at the same time want to generate html that is valid
  17. # [00:16] <Hixie> can you elaborate on that?
  18. # [00:16] <Hixie> what problem are you trying to solve with this?
  19. # [00:16] * Quits: darobin (~darobin@78.208.93.24) (Remote host closed the connection)
  20. # [00:16] <brainproxy> Hixie: see http://amundsen.com/hypermedia/profiles/
  21. # [00:17] <brainproxy> the idea is that you develop a semantic profile, where "rel" vals play an important role
  22. # [00:17] * Joins: darobin (~darobin@78.208.93.24)
  23. # [00:17] <Hixie> i have no idea what these words mean
  24. # [00:17] <Hixie> well that's not true
  25. # [00:17] <Hixie> i know what the words mean
  26. # [00:17] <brainproxy> the ALPS example is pretty short
  27. # [00:17] <Hixie> but put together in this order they don't add up to anything to me :-)
  28. # [00:17] <Hixie> i meant the words at http://amundsen.com/hypermedia/profiles/
  29. # [00:17] <brainproxy> the idea is that you document rel, class, name attrs
  30. # [00:18] <Hixie> the closest thing to a problem description there seems to be "The purpose of Application-Level Profile Semantics (ALPS) is to document the application-level semantics of a particular implementation." but i've no idea what that means
  31. # [00:18] <brainproxy> so that clients can be programmed to understand what they mean
  32. # [00:18] <brainproxy> but if you just use any old rel value, it's not valid html5
  33. # [00:18] <Hixie> can you give me a concrete example of what user-facing problem we're fixing with this?
  34. # [00:19] <brainproxy> it's another way to develop a hypermedia api using "semantic web" notions
  35. # [00:19] <zewt> ("hypermedia"? heh)
  36. # [00:20] <Hixie> what is a "hypermedia api"
  37. # [00:20] <brainproxy> basically term to suggest that the API embraces HATEOAS
  38. # [00:20] <Hixie> "HATEOAS"?
  39. # [00:20] <Hixie> assume i know nothing here, and start from zero :-)
  40. # [00:20] <brainproxy> hyertext/media as the engine of application state
  41. # [00:20] <Hixie> i'm a user, sitting at a computer
  42. # [00:20] <Hixie> what is my computer not doing that you are going to make it do
  43. # [00:21] <brainproxy> well this has more value for developers programming clients and servers based on web tech, and not necessarily joe smith using his browser
  44. # [00:22] * Quits: smaug____ (~chatzilla@a91-154-42-69.elisa-laajakaista.fi) (Ping timeout: 272 seconds)
  45. # [00:22] <Hixie> well smith using his browser
  46. # [00:22] <Hixie> er
  47. # [00:22] <Hixie> well, developers programming clients and servers based on web tech are still solving joe smith problems, right?
  48. # [00:23] <Hixie> like, they write tools to help them send short messages to their friends
  49. # [00:23] <brainproxy> the idea is that I can give you an entry point to my api, and armed w/ the semantic profile, you can build a client that can use the api w/o having to know some uri generation scheme
  50. # [00:23] <Hixie> or to manage their calendar
  51. # [00:23] <Hixie> or watch porn
  52. # [00:23] <Hixie> or whatever
  53. # [00:23] <Hixie> "uri generation scheme"?
  54. # [00:24] <Hixie> i feel like i'm missing some key context here
  55. # [00:24] <Hixie> what kind of API are we talking about?
  56. # [00:24] <brainproxy> in other words, my documented api revolves around the semantics of the hypermedia and not around documenting how to build up uris to do what you want to do
  57. # [00:24] <Hixie> sounds like your API is very complicated :-)
  58. # [00:24] <Hixie> can't you just have a simple API?
  59. # [00:24] <Hixie> what does your API do?
  60. # [00:25] * Quits: darobin (~darobin@78.208.93.24) (Ping timeout: 272 seconds)
  61. # [00:25] <brainproxy> well one in particular I'm building acts as a gateway between plain web (just html pages w/ links and forms) and industrial automation systems
  62. # [00:26] <brainproxy> so yes, there's a fair bit of complexity
  63. # [00:26] <Hixie> what is an "industrial automation system"? like, robots and stuff?
  64. # [00:27] * Quits: tndrH (~Rob@cpc4-seac20-2-0-cust858.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.88.2-rdmsoft [XULRunner 12.0/20120420145725])
  65. # [00:28] <brainproxy> well, in general devices you'd find in a manufacturing environment communicate w/ each other, and w/ centralized systems to keep track of what's going on
  66. # [00:28] <brainproxy> alarms, events, data changes, an so on
  67. # [00:28] <Hixie> ok...
  68. # [00:28] <Hixie> what's that got to do with HTML?
  69. # [00:28] <zewt> things i don't want my factory communicating with: the web
  70. # [00:28] <Hixie> yeah really
  71. # [00:29] <Hixie> air gap that sucker :-P
  72. # [00:29] <brainproxy> using web tech doesn't mean you hang your ass out of the factory's firewally on port 80
  73. # [00:29] <brainproxy> gimme a break :p
  74. # [00:30] <brainproxy> anyway, what it has to do w/ html; there are standards which govern how these things communicate
  75. # [00:30] <Hixie> please tell me they document binary TCP protocols that have nothing to do with HTTP
  76. # [00:30] <brainproxy> it's more than just wire protocols
  77. # [00:30] <brainproxy> and they do both binary and xml/soap
  78. # [00:30] <zewt> :|
  79. # [00:30] <Hixie> i think i see your problem :-)
  80. # [00:31] <brainproxy> it's all very stateful and not very nice to work with
  81. # [00:31] <Hixie> still don't see how this relates to HTML though
  82. # [00:31] <Hixie> let alone rel=""
  83. # [00:31] <brainproxy> well, i'm working on a gateway that one one side uses http/html as the application layer
  84. # [00:32] <brainproxy> and on the other side uses these industrial protocols
  85. # [00:32] <Hixie> i'll admit i know nothing about this at all, as should be clear from this conversation so far
  86. # [00:32] <Hixie> but that sounds like a terrible idea :-P
  87. # [00:32] <brainproxy> that's okay, you asked, so I was trying to explain it
  88. # [00:32] <brainproxy> i can stop if it's not interesting
  89. # [00:33] <Hixie> it is definitely interesting
  90. # [00:33] <brainproxy> anyway, Amundsen's ALPS thing and a book he wrote inspired me
  91. # [00:33] <brainproxy> but you end up generating a lot of rel values
  92. # [00:33] <brainproxy> which aren't registered
  93. # [00:33] <brainproxy> hence ... the option to use valid but non-registered rels is appealing
  94. # [00:33] <Hixie> what do these rel values mean?
  95. # [00:33] <brainproxy> they allow a client to understand what <a> is pointing to
  96. # [00:34] <Hixie> how, if there's no definiton?
  97. # [00:34] <Hixie> or are these entirely intended for proprietary use and not public web use?
  98. # [00:34] <brainproxy> there is, you document it, but it's not necessarily apt for publication in microformats
  99. # [00:35] <Hixie> i'm trying to work out what the consumption software for this is
  100. # [00:35] <Hixie> is this something that you would ever try to read from an unrelated third party?
  101. # [00:35] <Hixie> or is this all for use within a closed circle of people?
  102. # [00:36] * Quits: isherman-book (~Adium@173-167-102-230-sfba.hfc.comcastbusiness.net) (Quit: Leaving.)
  103. # [00:37] <brainproxy> unrelated third-parties could leverage the api to communicate w/ each other's systems
  104. # [00:37] <Hixie> on the web?
  105. # [00:38] <brainproxy> well across the global Internet yes, or intra-enterprise,
  106. # [00:38] * Quits: ralphholzmann (~ralphholz@li533-65.members.linode.com) (Remote host closed the connection)
  107. # [00:38] <brainproxy> and/or you could have small devices sporting a lightweight http/html stack use it to tie into the heavier-duty stuff
  108. # [00:39] <Hixie> it sounds to me like the solution to this is to define a specification for "Industrial API HTML definitions" or something, which introduces a new attribute like "api-rel" or whatever, which you can use for this purpose
  109. # [00:39] <Hixie> it doesn't sound like rel="" is the right thing at all
  110. # [00:40] <brainproxy> well no i disagree because rel conveys the meaning perfectly
  111. # [00:41] <Hixie> honestly it doesn't sound like HTML is the right thing at all, but I could see wanting to reuse it so that the same page could open both in a web browser and in this magical api software
  112. # [00:41] <brainproxy> and if someone wants to know what the heck rel="http://mycompany.com/rels/rel-1" means then they can look it up
  113. # [00:41] * Quits: Smylers (~smylers@host86-179-136-136.range86-179.btcentralplus.com) (Quit: Leaving.)
  114. # [00:41] <brainproxy> assuming I publishd documentation at the URI
  115. # [00:41] <brainproxy> it's not magical, you can write stuff like this easily with python or node.js or whatever
  116. # [00:42] <zewt> (why would you put a url in rel? that's totally wrong)
  117. # [00:42] <brainproxy> zewt: because that's what RFC 5988 recommendes
  118. # [00:42] <brainproxy> and the w3c editors saw the wisdom in it
  119. # [00:42] <brainproxy> and patched their spec
  120. # [00:42] <Hixie> doing things because an RFC recommends it is the worst possible reason to do something
  121. # [00:42] <Hixie> and the w3c editors didn't see the wisdom in it
  122. # [00:42] <brainproxy> Hixie: well if it's a bone-headed recommendation sure :)
  123. # [00:42] <Hixie> the w3c html chairs saw the wisdom
  124. # [00:43] <Hixie> and some w3c editors thought itwas so dumb they quit as editors :_)
  125. # [00:43] <brainproxy> so ... if want to know what rel="registered-rel" means
  126. # [00:43] <brainproxy> I can go look it up on microformats
  127. # [00:43] <Hixie> google [rel registered-rel]
  128. # [00:43] <brainproxy> or IANA i guess
  129. # [00:44] <brainproxy> but anyway, why is it bad to have the option to specify rel="http://mycompany.com/api/rels/rel-1"
  130. # [00:44] <brainproxy> and then joe blow client app developer can go look it up
  131. # [00:44] <brainproxy> on my wiki, or whatever that uri points him to
  132. # [00:44] <Hixie> what's bad is defining an API using rel="" :-)
  133. # [00:45] <brainproxy> nah, it's brililant
  134. # [00:45] <brainproxy> :D
  135. # [00:45] <brainproxy> and you don't use just rel of course
  136. # [00:45] <brainproxy> rel, class, name...
  137. # [00:46] <Hixie> o_O
  138. # [00:46] <Hixie> i really am at a loss
  139. # [00:46] <Hixie> why would anyone want to do this with HTML
  140. # [00:46] <brainproxy> read the ALPS thing, and here's an example
  141. # [00:46] <Hixie> i did read the ALPS thing
  142. # [00:46] <Hixie> it broke my buzzword detector
  143. # [00:46] <Hixie> and i didn't understand a word of it
  144. # [00:46] <brainproxy> https://github.com/mamund/Building-Hypermedia-APIs/tree/master/nodejs/microblog
  145. # [00:46] <Hixie> it was as bad as some of the Semantic Web stuff
  146. # [00:47] <brainproxy> that's an implemntation of Amundsen's ALPS, by the author, using nodejs
  147. # [00:47] <Hixie> what does it do?
  148. # [00:48] <brainproxy> it's a microblog which implements his semantic pofile
  149. # [00:48] <brainproxy> outlined in that document
  150. # [00:48] <Hixie> but what does it _do_?
  151. # [00:48] <brainproxy> it's a microblog
  152. # [00:48] <zewt> (what the heck is a microblog, aren't blogs micro by definition)
  153. # [00:48] <brainproxy> like Twitter, it's just an example
  154. # [00:48] <brainproxy> and this is a js bot which consumes the api
  155. # [00:48] <brainproxy> https://github.com/mamund/Building-Hypermedia-APIs/blob/master/nodejs/microblog/public/javascripts/mbclient.js
  156. # [00:48] <Hixie> zewt: microblog is basically like IRC but for hipsters :-)
  157. # [00:49] <Hixie> brainproxy: i don't understand why this is better than just having an API that you call directly
  158. # [00:49] <Hixie> brainproxy: it seems like a massive amount of extra work for no benefit
  159. # [00:50] <brainproxy> what do you mean by API you call directly?
  160. # [00:50] <Hixie> basically it's just an extra level of indirection
  161. # [00:50] <Hixie> instead of having to hardcode the API, you hardcode the values in rel="" etc, look up the API, and call the API
  162. # [00:50] <brainproxy> you mean by documenting URI construction rules?
  163. # [00:50] <Hixie> why not just call the API
  164. # [00:50] <Hixie> well I wouldn't use the term "URI construction rules", but sure
  165. # [00:50] * Joins: Druide_ (~Druid@p5B135EF5.dip.t-dialin.net)
  166. # [00:50] <brainproxy> well in this manner two different implementations could use completely different URI schemes
  167. # [00:50] <Hixie> personally i would do all these APIs over WebSocket these days
  168. # [00:50] <brainproxy> and it would work the same
  169. # [00:51] <Hixie> they could use completely different URI schemes but would still have to use identical rel="" etc schemes, right?
  170. # [00:51] <brainproxy> yes
  171. # [00:51] <Hixie> so where's the benefit
  172. # [00:51] <brainproxy> :/
  173. # [00:51] <Hixie> why not just define a little JSON blob that defines the mapping to the "URI construction rules"
  174. # [00:51] <Hixie> if you want to abstract those out
  175. # [00:52] <Hixie> (and why not just screw URLs entirely, and just document and implement a microblogging WebSocket protocol)
  176. # [00:52] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  177. # [00:52] <Hixie> (then anyone who wants to microblog can just use that protocol, regardless of the implementation)
  178. # [00:52] <brainproxy> websockets are nice for some things, but....
  179. # [00:52] <Hixie> things like microblogging APIs? :-)
  180. # [00:53] <brainproxy> websockets are stateful
  181. # [00:53] <brainproxy> for one
  182. # [00:53] <brainproxy> different paradigm
  183. # [00:55] <brainproxy> anyway, i'd like to see the option to use absolute URIs as rels, per rfc 5988 and the direction the w3c is going ... guess maybe whatwg isn't going that direction
  184. # [00:55] <brainproxy> got to get back to work, but thanks for chatting w/ me about it :)
  185. # [00:58] * Joins: auchenberg (~auchenber@176.222.239.226)
  186. # [01:03] * Quits: auchenberg (~auchenber@176.222.239.226) (Ping timeout: 264 seconds)
  187. # [01:10] * Quits: thisgeek (~chris@ool-45757782.dyn.optonline.net) (Quit: thisgeek)
  188. # [01:17] * Quits: jwalden (~waldo@c-71-202-165-226.hsd1.ca.comcast.net) (Quit: ChatZilla 0.9.87-5.1450hg.fc17 [XULRunner 15.0/20120827125645])
  189. # [01:17] * Joins: sicking (~chatzilla@c-67-180-8-184.hsd1.ca.comcast.net)
  190. # [01:19] * Joins: MikeSmith_ (~MikeSmith@manaslu.utelisys.net)
  191. # [01:19] * Quits: MikeSmith (~MikeSmith@manaslu.utelisys.net) (Read error: Connection reset by peer)
  192. # [01:19] * MikeSmith_ is now known as MikeSmith
  193. # [01:21] * Joins: MikeSmith_ (~MikeSmith@manaslu.utelisys.net)
  194. # [01:21] * Quits: MikeSmith (~MikeSmith@manaslu.utelisys.net) (Read error: Connection reset by peer)
  195. # [01:21] * MikeSmith_ is now known as MikeSmith
  196. # [01:36] * Joins: espadrine (~thaddee_t@85-218-9-34.dclient.lsne.ch)
  197. # [01:41] * Joins: manu1_ (~chatzilla@pool-96-240-164-148.ronkva.east.verizon.net)
  198. # [01:43] * Quits: manu1 (~chatzilla@pool-71-171-19-128.nwrknj.east.verizon.net) (Ping timeout: 260 seconds)
  199. # [01:43] * manu1_ is now known as manu1
  200. # [01:51] * Joins: nessy1 (~silviapf@124-169-159-193.dyn.iinet.net.au)
  201. # [01:57] * Quits: dbaron (~dbaron@70-36-140-99.dsl.dynamic.sonic.net) (Read error: Operation timed out)
  202. # [01:57] * Joins: dbaron (~dbaron@70-36-140-99.dsl.dynamic.sonic.net)
  203. # [02:00] * Quits: dbaron (~dbaron@70-36-140-99.dsl.dynamic.sonic.net) (Read error: Operation timed out)
  204. # [02:04] * Quits: sicking (~chatzilla@c-67-180-8-184.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  205. # [02:07] * Joins: danielfilho (~danielfil@201.52.236.78)
  206. # [02:09] * Quits: mattgifford (~mattgiffo@108.161.20.199) (Remote host closed the connection)
  207. # [02:13] * Quits: arunranga (~otherarun@pool-71-125-206-32.nycmny.east.verizon.net) (Quit: arunranga)
  208. # [02:13] * Quits: arunranga_ (~arunranga@pool-71-125-206-32.nycmny.east.verizon.net) (Quit: arunranga_)
  209. # [03:05] * Joins: jacobolus (~jacobolus@76.91.212.21)

The end :)