#rest on irc.freenode.net 2011-12-29 (txt)

[00:02] ivanfi (~ivanfi@62.159.77.166) joined #rest.
[00:45] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) got netsplit.
[00:45] Gracenotes (~person@wikipedia/Gracenotes) got netsplit.
[00:45] KevBurnsJr (~KevBurnsJ@50.0.103.39) got netsplit.
[00:45] tehviking (u2893@gateway/web/irccloud.com/x-epbiblrptvbxbiqp) got netsplit.
[00:45] KarlHungus (~relax@unaffiliated/adj) got netsplit.
[00:49] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) returned to #rest.
[00:49] Gracenotes (~person@wikipedia/Gracenotes) returned to #rest.
[00:49] KevBurnsJr (~KevBurnsJ@50.0.103.39) returned to #rest.
[00:49] tehviking (u2893@gateway/web/irccloud.com/x-epbiblrptvbxbiqp) returned to #rest.
[00:49] KarlHungus (~relax@unaffiliated/adj) returned to #rest.
[00:59] Wombert (~Wombert@client-gate.sfa.network.cynigram.com) joined #rest.
[01:42] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[01:52] grove (~grove@84.115.45.31.customer.cdi.no) joined #rest.
[02:21] mephju (~mephju@dslb-188-103-193-197.pools.arcor-ip.net) joined #rest.
[03:07] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 276 seconds
[03:32] sirex (~sirex@ubuntu/member/sirex) joined #rest.
[03:32] sirex (~sirex@ubuntu/member/sirex) left #rest ("Ex-Chat").
[04:17] ivanfi (~ivanfi@62.159.77.166) left irc: Read error: Connection reset by peer
[04:25] ivanfi (~ivanfi@62.159.77.166) joined #rest.
[04:26] ivanfi (~ivanfi@62.159.77.166) left #rest.
[05:15] mephju (~mephju@dslb-188-103-193-197.pools.arcor-ip.net) left irc: Quit: Ex-Chat
[05:40] Wombert (~Wombert@client-gate.sfa.network.cynigram.com) left irc: Quit: Wombert
[06:38] <mikekelly> contemplating making the case for partial PUT to the HTTPbis mailing list :)
[06:39] <mikekelly> just in case Roy wasn't certain about whether or not I'm an annoying prat :)
[06:52] mamund shows up
[06:52] mamund waves to the prat in the room
[07:00] <mikekelly> hiya!
[07:00] <mikekelly> :D
[07:00] <mikekelly> kind of annoyed about the trajectory of that media type meme thread
[07:01] <mikekelly> I tried to pull it off from the other one and focus it on the points for and against but it seems to have veered off into pedantry again
[07:05] <mamund> yeah, i'm not interesting in discussion the "semantics" of all this right now
[07:08] <mikekelly> mamund: I think I might have found some fancy words that kind of represent what I see as the difference between REST and semweb worlds
[07:09] <mikekelly> terminology rather, not words
[07:09] <mikekelly> REST is "non-essentialist"
[07:10] <mikekelly> semweb is "essentialist" view
[07:10] <mikekelly> that's based on my pathetic understanding of those terms as read from here http://en.wikipedia.org/wiki/Non-essentialism
[07:12] <mamund> hmmm
[07:12] <mikekelly> "In philosophy, essentialism is the view that, for any specific kind of entity, there is a set of characteristics or properties all of which any entity of that kind must possess. Therefore all things can be precisely defined or described. In this view, it follows that terms or words should have a single definition and meaning."
[07:14] <mamund> interesting. i might look into this.
[07:14] <mamund> i tend to use closed-world (sw) and open-world (rest)
[07:15] <mamund> http://en.wikipedia.org/wiki/Closed_world_assumption
[07:15] <mikekelly> afaict, non-essentialism is kind of aligned with the idea that a resource has its meaning projected onto it from the 'context' of a preceding link
[07:16] <mamund> huh
[07:18] <mikekelly> maybe I'm just looking for this
[07:18] <mikekelly> http://en.wikipedia.org/wiki/Relational_theory
[07:22] <mikekelly> that sounds awesome. must read more about this subject.
[07:24] <mamund> wow!
[07:25] <mikekelly> that is pretty much a perfect analogy for how I see linking
[07:25] <mikekelly> and rest
[07:25] <mikekelly> vs. all the semweb stuff
[07:26] <mamund> could be...
[07:26] <mamund> this is above my head right now, but v. interesting.
[07:28] <mikekelly> lol
[07:29] <mikekelly> reading about spin networks in loop quantum gravity theory
[07:32] <mamund> sheesh!
[07:54] <mamund> mikekelly: thought you'd like this one: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03990.html
[07:54] <mamund> moo-ha-ha-ha-ha-haaaa
[07:56] <mamund> wait!
[07:56] <mamund> that's not the right thread!
[08:22] <mamund> mikekelly: here's the msg i had in mind: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03991.html
[08:43] <mikekelly> oh god.
[08:43] <mikekelly> just.. what?
[08:43] <mikekelly> cmon..
[08:43] <mikekelly> seriously?!
[08:44] <mikekelly> :|
[08:44] <mikekelly> it would be super awesome if one of them explained why we need fullness visible in PUT messages
[08:45] <mikekelly> people keep using visibility as an argument in a lot of discussions recently
[08:45] <mikekelly> but using it like a buzzword without actually following through and explaining what the value of making whatever-property-of-the-message visible
[08:46] <mikekelly> is
[08:46] <mamund> i thought this would brigthen you day<g>
[08:46] <mikekelly> which is incredibly irritating.
[08:46] <mikekelly> "we need visibility in interactions, so you can't take that semantic away"
[08:47] <mikekelly> holy shit then I guess we had better work on a "what day the client decided it was going to make the request" header
[08:47] <mikekelly> so we get EVEN MORE VISIBILITY
[08:47] <mikekelly> and then maybe another header for like..
[08:47] <mikekelly> how the client and server were feeling when they sent their request/response
[08:47] <mikekelly> yet more visibility
[08:48] mamund is so happy now
[08:48] <mikekelly> Jan does this with visibility and Eric Bowman does the same thing with self-descriptiveness
[08:49] <mikekelly> :@
[09:13] <mikekelly> mamund: ruh roh I just contradicted your last post on media types :)
[09:15] <mikekelly> what do you think about that last paragraph? :
[09:15] <mikekelly> "Those additional assumptions can instead be made by understanding the link which led the client there, which should be the case for any resource except entry points. Exposing an app this way coaxes clients into traversing your application properly (out from entry points by following links), and it implies to consumers of your app that the representation's purpose and structure are impermanent - both of these are important implications if you want to fo
[09:17] <mamund> i'm not a fan of the "assumptions can be made by understanding thelink which let the client here..."
[09:17] <mikekelly> why?
[09:17] <mamund> this sounds 'stateful' to me.
[09:17] <mikekelly> say what now ?!
[09:17] <mikekelly> client state?
[09:17] <mamund> no- state-dependent on previous knowledge
[09:18] <mikekelly> state transitions?
[09:18] <mamund> IOW, if i store the output (cache it), i will possibly not know the link which let the client here
[09:18] <mikekelly> how is that possible ?
[09:19] <mikekelly> should probably post this to the list
[09:19] <mamund> are you saying i need to inspect the _link_ or the _rel_ associated with that link?
[09:19] <mikekelly> the rel of the link
[09:20] <mamund> how will my cached copy know the rel of that link
[09:23] <mikekelly> I don't undestand that question
[09:23] <mikekelly> the cached copy doesn't know the rel of that link
[09:23] <mikekelly> it's just a cached copy of state
[09:25] <mikekelly> "A REST API should be entered with no prior knowledge beyond the initial URI. From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations."
[09:25] <mamund> yeah, so "asumptions can be made by understanding the link[rel] which led the client here" is non-operable for copies of that message that are cached, right?
[09:25] <mikekelly> well a cached copy of something doesn't *do* anything
[09:25] <mikekelly> the client does something with it
[09:25] <mamund> LOL
[09:25] <mikekelly> cache is just an optimisation
[09:25] <mikekelly> what? that's true..
[09:25] <mikekelly> :S
[09:25] <mamund> the non-cached copy doesn't *do* anything, either
[09:26] <mikekelly> indeed.. caching is a network optimisation
[09:26] <mamund> ok, let me try asking it another way....
[09:27] <mamund> what information does the "link which led the client here" provide that will help in processing the response representation?
[09:27] <mikekelly> all that would happen is a client might traverse through a set of cached resources from an entry point when it 'comes back' to the application
[09:27] <mikekelly> that is a network optimisation, nothing more
[09:28] <mikekelly> it's a necessary optimisation for hypermedia applications
[09:28] <mikekelly> because traversals are 'chatty'
[09:28] <mikekelly> hence why cachign is a constraint
[09:28] <mikekelly> rather than a beneficial property
[09:29] <mikekelly> what information does the link provide? the rel.
[09:29] <mikekelly> and the rel asserts the sematnics
[09:30] <mikekelly> normal link relation stuff
[09:30] <mamund> so, picking up on the last sentence...
[09:30] <mamund> the rel asserts the semantics, and those semantics are _not_ actually in the response representation...
[09:30] <mikekelly> nope
[09:30] <mamund> IOW, the rel is *required* to understand the response representation, right?
[09:31] <mikekelly> unless it's an entry point
[09:31] <mikekelly> that is *THE* distinction between an entry point and any other resource
[09:32] <mikekelly> "A REST API should be entered with no prior knowledge beyond the initial URI. From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations."
[09:32] <mikekelly> that is exactly what that sentence says.. no ?
[09:32] <mamund> nothing about rels here
[09:32] <mikekelly> "client selection of server-provided choices" ?
[09:33] <mamund> and....?
[09:33] <mikekelly> ....
[09:33] <mamund> do forms have rels?
[09:33] <mikekelly> (that are not prior knowledge)
[09:33] <mikekelly> well I guess you could use some other name for them,
[09:33] <mikekelly> it's still a link relation
[09:34] <mikekelly> it's a token that lets you pick between links
[09:34] <mikekelly> ok ok + forms but let's just stick to sensible m2m mechanisms
[09:34] <mamund> how does the token on an HTML form help the client understand the response?
[09:34] <mamund> ahhh
[09:34] <mamund> this is about m2m
[09:34] <mikekelly> well
[09:34] <mikekelly> really
[09:34] <mikekelly> forms could/should have rels
[09:34] <mikekelly> so
[09:34] <mikekelly> it's mute
[09:35] <mamund> :)
[09:35] <mikekelly> really..
[09:35] <mikekelly> what's the differnece ? other than a form has a variable output
[09:35] <mikekelly> it's still a relation
[09:35] <mikekelly> and a link
[09:35] <mamund> i tossed in forms to test your "rel === understanding of the response" assertion
[09:36] <mikekelly> well a URI template is a 'form'
[09:36] <mamund> yep
[09:36] <mikekelly> and HAL treats them as normal links
[09:36] <mikekelly> with a rel
[09:36] <mikekelly> so
[09:36] <mikekelly> there is literally no difference there
[09:36] <mikekelly> in html terms it's really only a difficiency of HTML that prevents that
[09:37] <mikekelly> it would make perfect sense to have say..
[09:37] <mikekelly> <form rel="search" ...
[09:37] <mamund> yes, it would. but that is not what happens today
[09:37] <mamund> so i ask again, what is it in an HTML.FORM that helps the client to understand the response representation?
[09:37] <mikekelly> sure but we're talking about rest not web arch
[09:37] <mikekelly> lol
[09:38] <mikekelly> the implicit link relation
[09:38] <mamund> so, there are times when the client will use the rel of the refer link to understand the response representation, right?
[09:38] <mikekelly> the 'go' in the green form submit button
[09:38] <mikekelly> or 'purchase'
[09:38] <mikekelly> or 'go to checkout'
[09:38] <mamund> ok, that helps the human, not the code, right?
[09:38] <mikekelly> it's exactly the same thing it's just more fuzzy because people are fuzzy
[09:38] <mamund> yes, i follow that last line
[09:38] <mikekelly> right but that's where the application is..
[09:38] <mikekelly> with the actor
[09:39] <mamund> ok, now i think see your assertion.
[09:39] <mikekelly> the other shit is just a means to an ends.. to help the server and actor exchange information
[09:39] <mamund> interpretation of teh response is dependent on the "semantic meaning" of the link used to get that response.
[09:39] <mamund> is that about right?
[09:39] <mikekelly> yeah sounds ok
[09:39] <mikekelly> dunno what was mising in my original assertion
[09:40] <mamund> ok, so in the case of humans, they "interpret" the response based on the text they use when making a selection
[09:40] <mikekelly> sort of - but look humans are weird you can 'boot' a human with text and images which explain where they are
[09:40] <mamund> ok, so in the case of machines, they "interpret" the response based on the rel (or other token) they use when making a selection
[09:40] <mamund> right?
[09:41] <mikekelly> so you could type in a link into a browser that shoved them half-way into a checkout process and have a good enough GUI to indicate to them what they were doing, what they had in their basket, and that they needed to get their credit card out of their wallet
[09:41] <mikekelly> but to be honest that's not terribly interesting to me
[09:42] <mikekelly> it's just a reflection of how good humans are at stuff like that, and how much we can get away with from an application-design pov when the actor is a human
[09:42] <mamund> ok, i gotta do a mtg, but i want to pursue this a bit more.
[09:42] <mikekelly> cool me to
[09:42] <mikekelly> catch you later
[09:42] <mikekelly> if I'm not around just attack me on the mailing list
[09:42] <mikekelly> :D
[09:42] <mamund> your last statment suggests that there are cases where, even without a "rel/token/text" certain "agents" are able to infer meaning (i.e. dropped inthe middle of the checkout process)
[09:55] <mikekelly> well yeah that certain type of agents I call 'people'
[10:31] mike (~mike@ks391369.kimsufi.com) joined #rest.
[10:31] mike -> Guest39403
[10:35] Guest39403 -> mikekelly_
[10:36] <mikekelly_> DIE
[10:36] <mikekelly_> :)
[10:36] <mamund> dye?
[10:37] <mikekelly> strange happenings.
[10:37] mikekelly (~mike@ks391369.kimsufi.com) left irc: Quit: leaving
[10:37] <mamund> as in "the roll of the die"?
[10:38] mikekelly_ -> mikekelly
[10:38] <mikekelly> nice
[10:38] <mamund> sorry
[10:38] <mikekelly> decided to go back to a GUI IRC channel
[10:38] mamund hangs his head
[10:39] <mamund> !
[10:39] <mikekelly> GUI IRC client
[10:39] <mikekelly> too much christmas drinking !!
[10:40] <mamund> :)
[10:40] <mikekelly> well Jan hasn't come back yet
[10:40] <mikekelly> which is a bit dissapointing
[11:01] <mamund> ok, production update applied, tests passed. i can relax a bit
[11:07] grove (~grove@84.115.45.31.customer.cdi.no) got netsplit.
[11:18] grove (~grove@84.115.45.31.customer.cdi.no) got lost in the net-split.
[11:28] <mikekelly> :)
[11:41] twilliams (~twilliams@apache/committer/twilliams) joined #rest.
[11:44] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving...
[12:19] Wombert (~Wombert@client-gate.sfa.network.cynigram.com) joined #rest.
[13:18] Wombert (~Wombert@client-gate.sfa.network.cynigram.com) left irc: Quit: Wombert
[14:58] Wombert (~Wombert@2001:5a8:4:6d6e:c847:36a4:3647:b0da) joined #rest.
[15:31] mamund toodles!
[16:31] <mikekelly> noo
[16:35] <mikekelly> anyone following this media type meme thread ?
[16:44] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) left irc: Ping timeout: 252 seconds
[16:51] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) joined #rest.
[17:22] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[18:30] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[18:30] prnightmare (~will@cpe-66-66-139-106.rochester.res.rr.com) joined #rest.
[19:18] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[19:35] prnightmare (~will@cpe-66-66-139-106.rochester.res.rr.com) left #rest.
[19:40] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Read error: Connection reset by peer
[19:40] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[19:45] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Read error: Operation timed out
[19:45] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[20:06] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 268 seconds
[20:19] quest88 (~quest88@adsl-75-23-35-7.dsl.lgvwtx.sbcglobal.net) joined #rest.
[20:48] Wombert (~Wombert@2001:5a8:4:6d6e:c847:36a4:3647:b0da) left irc: Quit: Wombert
[22:02] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[22:09] quest88 (~quest88@adsl-75-23-35-7.dsl.lgvwtx.sbcglobal.net) left irc: Quit: quest88
[22:15] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Ping timeout: 248 seconds
[22:16] Wombert (~Wombert@2001:5a8:4:6d6e:cdfd:dead:d8c8:b579) joined #rest.
[22:36] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[23:20] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) left irc: Ping timeout: 248 seconds
[23:22] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) joined #rest.
[00:00] --- Fri Dec 30 2011