[00:02:50] ivanfi (~ivanfi@62.159.77.166) joined #rest. [00:45:35] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) got netsplit. [00:45:35] Gracenotes (~person@wikipedia/Gracenotes) got netsplit. [00:45:35] KevBurnsJr (~KevBurnsJ@50.0.103.39) got netsplit. [00:45:35] tehviking (u2893@gateway/web/irccloud.com/x-epbiblrptvbxbiqp) got netsplit. [00:45:36] KarlHungus (~relax@unaffiliated/adj) got netsplit. [00:49:10] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) returned to #rest. [00:49:10] Gracenotes (~person@wikipedia/Gracenotes) returned to #rest. [00:49:10] KevBurnsJr (~KevBurnsJ@50.0.103.39) returned to #rest. [00:49:10] tehviking (u2893@gateway/web/irccloud.com/x-epbiblrptvbxbiqp) returned to #rest. [00:49:10] KarlHungus (~relax@unaffiliated/adj) returned to #rest. [00:59:33] Wombert (~Wombert@client-gate.sfa.network.cynigram.com) joined #rest. [01:42:32] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest. [01:52:43] grove (~grove@84.115.45.31.customer.cdi.no) joined #rest. [02:21:11] mephju (~mephju@dslb-188-103-193-197.pools.arcor-ip.net) joined #rest. [03:07:19] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 276 seconds [03:32:18] sirex (~sirex@ubuntu/member/sirex) joined #rest. [03:32:32] sirex (~sirex@ubuntu/member/sirex) left #rest ("Ex-Chat"). [04:17:41] ivanfi (~ivanfi@62.159.77.166) left irc: Read error: Connection reset by peer [04:25:52] ivanfi (~ivanfi@62.159.77.166) joined #rest. [04:26:23] ivanfi (~ivanfi@62.159.77.166) left #rest. [05:15:23] mephju (~mephju@dslb-188-103-193-197.pools.arcor-ip.net) left irc: Quit: Ex-Chat [05:40:04] Wombert (~Wombert@client-gate.sfa.network.cynigram.com) left irc: Quit: Wombert [06:38:15] contemplating making the case for partial PUT to the HTTPbis mailing list :) [06:39:19] just in case Roy wasn't certain about whether or not I'm an annoying prat :) [06:52:26] Action: mamund shows up [06:52:40] Action: mamund waves to the prat in the room [07:00:06] hiya! [07:00:07] :D [07:00:37] kind of annoyed about the trajectory of that media type meme thread [07:01:04] 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:52] yeah, i'm not interesting in discussion the "semantics" of all this right now [07:08:56] 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:14] terminology rather, not words [07:09:43] REST is "non-essentialist" [07:10:03] semweb is "essentialist" view [07:10:59] that's based on my pathetic understanding of those terms as read from here http://en.wikipedia.org/wiki/Non-essentialism [07:12:34] hmmm [07:12:45] "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:18] interesting. i might look into this. [07:14:46] i tend to use closed-world (sw) and open-world (rest) [07:15:18] http://en.wikipedia.org/wiki/Closed_world_assumption [07:15:40] 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:03] huh [07:18:18] maybe I'm just looking for this [07:18:46] http://en.wikipedia.org/wiki/Relational_theory [07:22:12] that sounds awesome. must read more about this subject. [07:24:41] wow! [07:25:26] that is pretty much a perfect analogy for how I see linking [07:25:37] and rest [07:25:43] vs. all the semweb stuff [07:26:27] could be... [07:26:43] this is above my head right now, but v. interesting. [07:28:44] lol [07:29:10] reading about spin networks in loop quantum gravity theory [07:32:32] sheesh! [07:54:31] mikekelly: thought you'd like this one: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03990.html [07:54:48] moo-ha-ha-ha-ha-haaaa [07:56:17] wait! [07:56:23] that's not the right thread! [08:22:30] mikekelly: here's the msg i had in mind: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03991.html [08:43:38] oh god. [08:43:51] just.. what? [08:43:56] cmon.. [08:43:58] seriously?! [08:44:00] :| [08:44:51] it would be super awesome if one of them explained why we need fullness visible in PUT messages [08:45:11] people keep using visibility as an argument in a lot of discussions recently [08:45:55] 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:01] is [08:46:16] i thought this would brigthen you day [08:46:19] which is incredibly irritating. [08:46:44] "we need visibility in interactions, so you can't take that semantic away" [08:47:20] 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:25] so we get EVEN MORE VISIBILITY [08:47:36] and then maybe another header for like.. [08:47:51] how the client and server were feeling when they sent their request/response [08:47:58] yet more visibility [08:48:47] Action: mamund is so happy now [08:48:57] Jan does this with visibility and Eric Bowman does the same thing with self-descriptiveness [08:49:06] :@ [09:13:55] mamund: ruh roh I just contradicted your last post on media types :) [09:15:14] what do you think about that last paragraph? : [09:15:16] "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:00] i'm not a fan of the "assumptions can be made by understanding thelink which let the client here..." [09:17:08] why? [09:17:14] this sounds 'stateful' to me. [09:17:19] say what now ?! [09:17:23] client state? [09:17:44] no- state-dependent on previous knowledge [09:18:03] state transitions? [09:18:12] IOW, if i store the output (cache it), i will possibly not know the link which let the client here [09:18:27] how is that possible ? [09:19:02] should probably post this to the list [09:19:04] are you saying i need to inspect the _link_ or the _rel_ associated with that link? [09:19:17] the rel of the link [09:20:10] how will my cached copy know the rel of that link [09:23:00] I don't undestand that question [09:23:07] the cached copy doesn't know the rel of that link [09:23:32] it's just a cached copy of state [09:25:01] "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:02] 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:31] well a cached copy of something doesn't *do* anything [09:25:36] the client does something with it [09:25:42] LOL [09:25:42] cache is just an optimisation [09:25:48] what? that's true.. [09:25:50] :S [09:25:55] the non-cached copy doesn't *do* anything, either [09:26:08] indeed.. caching is a network optimisation [09:26:50] ok, let me try asking it another way.... [09:27:12] what information does the "link which led the client here" provide that will help in processing the response representation? [09:27:15] 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:23] that is a network optimisation, nothing more [09:28:11] it's a necessary optimisation for hypermedia applications [09:28:16] because traversals are 'chatty' [09:28:29] hence why cachign is a constraint [09:28:53] rather than a beneficial property [09:29:43] what information does the link provide? the rel. [09:29:58] and the rel asserts the sematnics [09:30:09] normal link relation stuff [09:30:18] so, picking up on the last sentence... [09:30:42] the rel asserts the semantics, and those semantics are _not_ actually in the response representation... [09:30:57] nope [09:30:59] IOW, the rel is *required* to understand the response representation, right? [09:31:09] unless it's an entry point [09:31:21] that is *THE* distinction between an entry point and any other resource [09:32:23] "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:41] that is exactly what that sentence says.. no ? [09:32:42] nothing about rels here [09:32:59] "client selection of server-provided choices" ? [09:33:09] and....? [09:33:13] .... [09:33:18] do forms have rels? [09:33:21] (that are not prior knowledge) [09:33:29] well I guess you could use some other name for them, [09:33:44] it's still a link relation [09:34:04] it's a token that lets you pick between links [09:34:36] ok ok + forms but let's just stick to sensible m2m mechanisms [09:34:38] how does the token on an HTML form help the client understand the response? [09:34:43] ahhh [09:34:46] this is about m2m [09:34:49] well [09:34:51] really [09:34:56] forms could/should have rels [09:34:57] so [09:34:58] it's mute [09:35:00] :) [09:35:03] really.. [09:35:18] what's the differnece ? other than a form has a variable output [09:35:24] it's still a relation [09:35:26] and a link [09:35:45] i tossed in forms to test your "rel === understanding of the response" assertion [09:36:02] well a URI template is a 'form' [09:36:08] yep [09:36:23] and HAL treats them as normal links [09:36:25] with a rel [09:36:26] so [09:36:32] there is literally no difference there [09:36:53] in html terms it's really only a difficiency of HTML that prevents that [09:37:01] it would make perfect sense to have say.. [09:37:08]