#rest on irc.freenode.net 2012-01-05 (txt)

[00:28] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Read error: Connection reset by peer
[00:28] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) joined #rest.
[02:37] [S^K] (~S^K]@host-89-241-150-20.as13285.net) joined #rest.
[03:22] twilliams (~twilliams@apache/committer/twilliams) left irc: Quit: Computer went to sleep
[03:44] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[03:49] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving...
[03:51] twilliams (3f7d04d2@apache/committer/twilliams) joined #rest.
[03:51] twilliams (3f7d04d2@apache/committer/twilliams) left irc: Client Quit
[04:26] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest.
[04:26] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left #rest.
[04:31] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) joined #rest.
[06:06] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) joined #rest.
[07:20] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[08:05] [S^K] (~S^K]@host-89-241-150-20.as13285.net) left irc: Quit: Leaving
[08:07] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest.
[08:13] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left #rest.
[08:29] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) left irc: Quit: Leaving...
[08:36] mephju (~mephju@dslb-188-103-162-061.pools.arcor-ip.net) joined #rest.
[08:51] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest.
[08:56] mamund is here; better late than never!
[08:59] <mamund> mikekelly: just to let you know, i'm working up a blog post on the terms 'visiblity' and 'self-describing'
[09:00] <mamund> got the impetus from our short convo here this week.
[09:00] <mikekelly> hopefully you will Get It Right(tm)
[09:00] <mikekelly> :D
[09:00] <mamund> LOL
[09:00] <mamund> will give it a stab, but suspect the topic will require some exploration and refinement
[09:01] <mamund> hence the post!
[09:03] <mikekelly> look forward to it
[09:03] <mamund> me, too<g>.
[09:04] <mamund> basically i'm at: 'visbility' is for the protocol and is achieved via mesage metadata (headers)
[09:04] <mamund> and 'self-describing' is for the problem domain and is achieved via the message body
[09:05] <mamund> thye work orthagonally, but at times can affect each other, too.
[09:05] <mamund> it's important to keep them clear in your mind when implementing
[09:06] <mamund> after that it's all 'fluff'<g>
[09:06] <mikekelly> hmm, I'd always understood self-describing also being about protocol messages
[09:06] <mikekelly> as in it's the property that creates visibility
[09:06] <mamund> in that case "protocol messages" is the whole message (header+body), right?
[09:07] <mamund> i definitely see the importance of self-describing at the protocol level
[09:07] <mikekelly> no I don't include body in it at all
[09:08] <mamund> as in "the message is sufficiently self-descriptive in order to allow intermediaries the info they need for thier work"
[09:08] <mikekelly> actually that's not strictly true
[09:08] <mikekelly> "REST enables intermediate processing by constraining messages to be self-descriptive"
[09:09] <mamund> so, again, your POV is self-descriptive is protocol-level and has nothing to do w/ the body, right?
[09:09] <mikekelly> erm
[09:09] <mikekelly> well that's not true I just said something Id on't believe
[09:09] <mikekelly> :)
[09:09] <mamund> LOL
[09:09] <mamund> this is my focus, sorting this out
[09:10] <mamund> i;'m open for ideas and references, ec.
[09:10] <mikekelly> if the media type is standard then the body has self-descriptiveness
[09:10] <mamund> wow,
[09:10] <mamund> "standard" is in suffcient to me
[09:11] <mamund> if the media is _registered_ then...
[09:11] <mamund> is that what "standard" means?
[09:11] <mikekelly> nah fuck that
[09:11] <mamund> :)
[09:11] <mikekelly> besides:
[09:11] <mikekelly> "self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability."
[09:12] <mamund> well, that sounds like the contents of the body is not important, right?
[09:12] <mikekelly> no it is
[09:12] <mamund> the _contents_ of the body is important?
[09:12] <mikekelly> there are particular types of semantics that are important from a self-descriptive pov
[09:12] <mamund> hmmm
[09:12] <mamund> tell me more
[09:13] <mikekelly> e.g. the script tag and rel="stylesheet" in HTML
[09:14] <mikekelly> those are examples of visible semantics that create intermediary processability
[09:14] <mamund> see, now you are starting to sound like assertions i made at the top of this convo
[09:14] <mikekelly> you mean I'm contradicting myself?
[09:14] <mamund> heeee
[09:15] <mamund> or contradicting me! or both of us!
[09:15] <mikekelly> the best way of summing up my position is
[09:17] <mikekelly> if you tell me something is "self-descriptive" but then don't demonstrate how that thing is useful for intermediary processing - then I will call bs
[09:17] <mikekelly> as an example:
[09:17] <mikekelly> you could make part of your application that clients have to include their star sign and they emotional state at the time of making the request
[09:17] <mikekelly> in HTTP headers
[09:18] <mamund> :)
[09:18] <mikekelly> that is not /improving/ self-descriptiveness
[09:18] <mikekelly> it's just noise
[09:18] <mamund> this is good, we're on to talking about what "self-descriptive" _means_ for this case. i like that
[09:18] <mikekelly> and this leads to why I think custom media type identifiers are actually a Bad Thing..
[09:18] <mikekelly> :)
[09:18] <mamund> so, here's a thing...
[09:19] <mamund> define 'visibility' and define 'self-descriptiveness'
[09:19] <mamund> and do it w/o referring to the other
[09:19] mamund whips out pencil and paper
[09:20] <mamund> my aim here is so be able to say "that is not self-descriptive _because_ ..."
[09:20] <mamund> or "that is not visible _because_ ..."
[09:20] <mamund> *if* we can do that, then i think we have something.
[09:21] <mamund> yes, no?
[09:21] <mikekelly> visibility is the degree of semantic assertion intermediating parties can make about an interaction
[09:21] <mikekelly> is that ok ?
[09:22] <mamund> hmmm
[09:22] <mamund> possibly
[09:22] <mamund> lots there for me to chew on..
[09:22] <mikekelly> self-descriptiveness is the same thing
[09:22] <mamund> "semantic assertion"
[09:22] <mamund> ah!
[09:23] <mamund> same thing!
[09:23] <mamund> we don't need both?
[09:23] <mikekelly> probably not
[09:23] <mamund> hmmm
[09:23] <mamund> radical
[09:23] <mamund> ok, let's try this...
[09:23] <mikekelly> well
[09:23] <mamund> visibility is the _product_ of self-describing messages
[09:24] <mikekelly> visibility (as a quality) is a good word
[09:24] <mikekelly> visible messages doesn't sound as good as self-descriptive messages
[09:24] <mikekelly> it's self-descriptive isn't it ?
[09:24] <mamund> "in order to have visibility, we need self-desribing msgs"
[09:24] <mamund> is that true?
[09:25] <mikekelly> yeah
[09:25] <mamund> see, i'm not sure i buy this line of reasoning, but i'm open
[09:25] <mamund> i think you can have _some_ visibility w/o SDM
[09:25] <mikekelly> "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability."
[09:25] <mamund> yeah - no visibility there
[09:26] <mikekelly> "visibility is the degree of semantic assertion intermediating parties can make about an interaction"
[09:26] <mikekelly> "self-descriptiveness is the degree of semantic assertion intermediating parties can make about an interaction"
[09:26] <mamund> first, i think i will need to give up my assertion that sekf-describing is for app-level (message body), that was proly bad on my part
[09:27] <mamund> visibility is about the interaction, SDM is about the mesage itself
[09:27] <mamund> ?
[09:27] <mikekelly> there's a difference between those two things?
[09:27] <mamund> which two?
[09:27] <mikekelly> interaction vs the messages
[09:27] <mikekelly> the interaction is the messages..
[09:28] <mamund> hmmm
[09:28] <mikekelly> i *think* (and I haven't thought about this that much tbh) that it's really just a style thing
[09:28] <mamund> oh...
[09:28] <mamund> uh
[09:28] <mikekelly> they basically mean the same thing but they sound better in differnet contexts
[09:28] <mamund> ok
[09:28] <mamund> i see where you are going
[09:29] <mamund> i want to ponder that
[09:29] <mikekelly> that could be shite btw
[09:29] <mamund> so, your POV is you can't really have V w/ SDM
[09:29] <mikekelly> exactly
[09:29] <mamund> well, no more sh*t-ridden than my musings, tbh
[09:29] <mamund> <g>
[09:29] <mamund> ok
[09:29] <mamund> let me work on that for a bit
[09:29] <mikekelly> Link headers can be used to "beef up" the uniform interface by expressing these invisible dependencies as link relations.
[09:29] <mikekelly> Standardising the link relations allows these links to be used as control data within the uniform interface; thus increasing self-descriptiveness of messages and visibility."
[09:30] <mikekelly> that's from that link header stuff I did
[09:30] <mamund> ok
[09:30] <mikekelly> so I copped out and just said it improved them both
[09:30] <mikekelly> :D
[09:30] <mamund> LOL
[09:30] <mamund> yeah
[09:30] <mikekelly> or covered all the bases..
[09:30] <mikekelly> depending on how you look at it
[09:30] <mamund> so my next Q is this...
[09:30] <mamund> you con't get V w/o SDM
[09:30] <mamund> is it true in the inverse?
[09:31] <mamund> you don't get SDM w/o V?
[09:31] <mamund> i think that's not right
[09:31] <mamund> but...
[09:31] <mamund> may not matter
[09:31] <mamund> i appreciate your POV.
[09:31] <mikekelly> well that's just because of the wording right
[09:31] <mikekelly> if you change it ot
[09:31] <mamund> since you've got exp. in the intermediary space, i think your POV is well-informed in this in general
[09:31] <mikekelly> you don't get self-descriptiveness without visible messages
[09:32] <mamund> hmmm
[09:32] <mamund> ok
[09:32] <mamund> V depends on SDM
[09:32] <mikekelly> you don't get visibility without visible messages
[09:32] <mamund> :)
[09:32] <mikekelly> you don't get self-descriptiveness without SDM
[09:32] <mamund> the full truth table in action!
[09:32] <mikekelly> :p
[09:33] <mamund> ok, thanks for your help.
[09:33] <mamund> i'll noodle for a bit and proly hit you up again soon.
[09:33] <mikekelly> right, I'm sure that was super duper helpful! :D
[09:34] <mikekelly> me contradicting myself and then making dumb tautological statements
[09:34] <mikekelly> you're probably used to that by now though
[09:35] <mikekelly> fwiw in my talk about link headers I used 'visibility' to talk about improving the visibility of the 'system' (i.e. the web)
[09:38] <mikekelly> i.e. standardizing the link relations made them self-descriptive, which resulted in more visibility in the system wrt 'resource dependencies'
[09:39] <mikekelly> could've swapped them round though and still would be the same sentiment, just wouldn't read as well (for me, anyway)
[09:39] <mikekelly> you never know you might wake Roy up with this, he's the expert after all :)
[09:40] <mamund> LOL
[09:40] <mikekelly> Dude needs to get a clue about partial PUT though.. amirite?!?!?!
[09:40] <mamund> well, IMO< just like i spent the last two years getting people to talk more definitively about media types...
[09:40] <mamund> i'd like to get folks to talk more defintively about this visible/self-describptive stuff
[09:40] <mamund> it matter,s, IMO.
[09:41] <mikekelly> it's really good you're putting that into words - it's seriously important
[09:41] <mamund> yep
[09:41] <mamund> i am not so concerned that folks share my POV on these things...
[09:41] <mamund> i,m most interested in geting us all to talk about the _same_ thing when we use the terms.
[09:41] <mikekelly> indeed
[09:42] <mamund> anyway, i appreciate the info.
[09:42] <mikekelly> it'll help me because it forms the basis for my argument against specific media types :)
[09:42] <mamund> i'd like to get some basic "stakes in the ground" _before_
[09:42] <mamund> starting this up in the rest-discuss
[09:42] <mamund> thing to tamp down the wandering randomness of some threads
[09:43] <mamund> ok, gonna take a break now
[09:43] <mikekelly> yep, will definitely help - provided people actually want to go through the hassel of actually thinking/explaining what they mean
[09:43] <mikekelly> :)
[09:43] <mamund> LOL, so true.
[09:44] mamund haeds out for a break
[09:44] Hakon|mbp (~hakon1@81.80-202-248.nextgentel.com) joined #rest.
[09:50] Hakon|mbp (~hakon1@81.80-202-248.nextgentel.com) left irc: Quit: Leaving...
[10:05] <whartung> hi all
[10:13] Hakon|mbp (~hakon1@62.97.234.170) joined #rest.
[10:22] KevBurnsJr (~KevBurnsJ@50.0.103.39) left irc:
[10:23] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest.
[10:36] mamund is back
[10:36] <mamund> whartung: \o
[10:39] Hakon|mbp (~hakon1@62.97.234.170) left irc: Quit: Leaving...
[10:53] mephju (~mephju@dslb-188-103-162-061.pools.arcor-ip.net) left irc: Ping timeout: 255 seconds
[11:07] mephju (~mephju@141.44.227.131) joined #rest.
[13:30] <mamund> argghhhh!
[13:30] <mamund> my IETF I-D (on link relations) is blocked
[13:30] <mamund> i have a bad reference to a related doc and need to change a sentence.
[13:31] <mamund> oh, well
[13:31] mamund shrugs
[13:31] <mamund> will wait a bit longer, then
[13:39] Hakon|mbp (~hakon1@62.97.234.170) joined #rest.
[13:40] Hakon|mbp (~hakon1@62.97.234.170) left irc: Client Quit
[13:50] 92AAAAABZ -> scott___
[13:50] scott___ -> scott|
[13:53] KevBurnsWork (~KevBurnsW@50.0.103.39) joined #rest.
[14:14] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Quit: Wombert
[14:15] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) joined #rest.
[14:20] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Ping timeout: 244 seconds
[14:41] Hakon|mbp (~hakon1@62.97.234.170) joined #rest.
[14:42] Hakon|mbp (~hakon1@62.97.234.170) left irc: Client Quit
[14:54] mephju (~mephju@141.44.227.131) left irc: Quit: Ex-Chat
[15:06] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) joined #rest.
[15:22] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Quit: Wombert
[15:38] KevBurnsWork (~KevBurnsW@50.0.103.39) left irc:
[15:39] pc1oad1etter_ (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) joined #rest.
[15:58] pc1oad1etter_ (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) left irc: Quit: pc1oad1etter_
[16:14] mamund is done here. carry on.
[16:16] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[16:48] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 248 seconds
[18:09] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[18:11] KevBurnsJr (~KevBurnsJ@50.0.103.39) left irc:
[19:12] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[19:40] fu-manchu (~fumanchu@adsl-99-30-180-185.dsl.sfldmi.sbcglobal.net) left irc: Ping timeout: 240 seconds
[19:59] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) left irc: Ping timeout: 260 seconds
[20:01] fu-manchu (~fumanchu@adsl-99-30-180-185.dsl.sfldmi.sbcglobal.net) joined #rest.
[20:02] SvenDowideit (~SvenDowid@203-206-171-38.perm.iinet.net.au) joined #rest.
[20:30] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 244 seconds
[20:52] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) joined #rest.
[22:27] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) joined #rest.
[23:08] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Quit: quest88
[00:00] --- Fri Jan 6 2012