[00:11:01] KevBurnsJr (~kevburnsj@c-67-169-94-104.hsd1.ca.comcast.net) left irc: 
[00:16:31] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[00:23:02] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove
[00:26:02] jaminja (~jaminja@unaffiliated/jaminja) left irc: Read error: Operation timed out
[00:31:47] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[00:47:55] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:49:02] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:59:40] ivanfi (~ivanfi@62.159.77.164) joined #rest.
[01:05:36] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[01:06:26] mephju (~mephju@dslb-094-222-010-037.pools.arcor-ip.net) joined #rest.
[01:57:09] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[02:23:43] mephju_ (~mephju@dslb-094-222-010-037.pools.arcor-ip.net) joined #rest.
[02:24:06] <mikekelly> crazy how busy it is in this channel these days.. :)
[02:24:45] mephju_ (~mephju@dslb-094-222-010-037.pools.arcor-ip.net) left irc: Client Quit
[02:24:57] <mikekelly> was just 2 or 3 of us not so long ago
[03:03:45] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) joined #rest.
[03:18:37] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[03:18:38] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[03:18:38] Nick change: grove_ -> grove
[03:21:01] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[03:28:23] v-dogg (vmakinen@kapsi.fi) got netsplit.
[03:28:24] `0660 (olli@oosny.net) got netsplit.
[03:28:24] trygvis (trygvela@knuth.ping.uio.no) got netsplit.
[03:28:24] fumanchu (~fumanchu@99.30.180.185) got netsplit.
[03:28:25] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) got netsplit.
[03:28:29] ivanfi (~ivanfi@62.159.77.164) got netsplit.
[03:28:29] jaminja (~jaminja@unaffiliated/jaminja) got netsplit.
[03:28:32] impl (impl@atheme/member/impl) got netsplit.
[03:28:32] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) got netsplit.
[03:28:33] mamund (mamund@69.163.32.100) got netsplit.
[03:28:34] whartung (~whartung@wsip-98-189-78-118.oc.oc.cox.net) got netsplit.
[03:28:37] tef (tef@void.printf.net) got netsplit.
[03:28:40] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) got netsplit.
[03:28:40] dreinull (~dreieins@217.18.70.225) got netsplit.
[03:28:41] twilliams (~twilliams@apache/committer/twilliams) got netsplit.
[03:28:41] Split (~split@84.34.147.60) got netsplit.
[03:28:41] mogsie (~mogsie@62.101.198.35) got netsplit.
[03:28:42] HighBit (~eqhmcow@adsl-98-69-182-207.rmo.bellsouth.net) got netsplit.
[03:32:38] ivanfi (~ivanfi@62.159.77.164) returned to #rest.
[03:32:38] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) returned to #rest.
[03:32:38] jaminja (~jaminja@unaffiliated/jaminja) returned to #rest.
[03:32:38] mamund (mamund@69.163.32.100) returned to #rest.
[03:32:38] tef (tef@void.printf.net) returned to #rest.
[03:32:38] whartung (~whartung@wsip-98-189-78-118.oc.oc.cox.net) returned to #rest.
[03:32:38] impl (impl@atheme/member/impl) returned to #rest.
[03:32:38] #rest: mode change '+o mamund  ' by calvino.freenode.net
[03:33:01] HighBit (~eqhmcow@adsl-98-69-182-207.rmo.bellsouth.net) returned to #rest.
[03:33:12] v-dogg (vmakinen@kapsi.fi) returned to #rest.
[03:33:13] `0660 (olli@oosny.net) returned to #rest.
[03:33:13] trygvis (trygvela@knuth.ping.uio.no) returned to #rest.
[03:33:13] fumanchu (~fumanchu@99.30.180.185) returned to #rest.
[03:34:41] dreinull (dreieins@217.18.70.225) joined #rest.
[03:38:06] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[03:39:00] mogsie (~mogsie@62.101.198.35) got lost in the net-split.
[03:39:00] Split (~split@84.34.147.60) got lost in the net-split.
[03:39:00] twilliams (~twilliams@apache/committer/twilliams) got lost in the net-split.
[03:39:00] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) got lost in the net-split.
[03:39:00] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) got lost in the net-split.
[03:42:37] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[03:42:45] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[03:51:37] mogsie (~mogsie@62.101.198.35) joined #rest.
[03:57:52] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 258 seconds
[03:58:00] Split (~split@84.34.147.60) joined #rest.
[04:03:32] jaminja (~jaminja@76.76.24.43) joined #rest.
[04:06:08] jaminja (~jaminja@76.76.24.43) left irc: Changing host
[04:06:08] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[04:07:11] ssedano (~ssedano@unaffiliated/ssedano) joined #rest.
[04:16:33] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[04:16:33] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[04:16:33] Nick change: grove_ -> grove
[04:18:45] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[04:18:45] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[04:18:45] Nick change: grove_ -> grove
[04:33:54] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[04:33:54] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[04:33:54] Nick change: grove_ -> grove
[05:48:50] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[05:49:19] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[05:49:20] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[05:49:20] Nick change: grove_ -> grove
[05:49:56] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[05:49:57] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[05:49:57] Nick change: grove_ -> grove
[06:27:47] bigbluehat (~bigblueha@68-115-173-74.static.ahvl.nc.charter.com) joined #rest.
[06:32:28] bigbluehat (~bigblueha@68-115-173-74.static.ahvl.nc.charter.com) left irc: Ping timeout: 260 seconds
[06:35:40] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[06:57:30] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[06:57:30] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[06:57:31] Nick change: grove_ -> grove
[07:00:20] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest.
[07:21:08] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove
[07:41:41] <darrelmiller> mikekelly:  We also seem to be improving the participant vs lurker ratio.
[07:50:23] ivanfi (~ivanfi@62.159.77.164) left irc: Quit: Leaving.
[08:02:45] darrelmiller (~darrelmil@bas3-montreal50-1177637007.dsl.bell.ca) left irc: Ping timeout: 252 seconds
[08:07:08] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[08:23:47] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[08:27:02] darrelmiller (~darrelmil@bas3-montreal50-2925371499.dsl.bell.ca) joined #rest.
[08:29:40] Action: mamund makes an appearance
[08:31:26] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 276 seconds
[08:32:08] jaminja (~jaminja@76.76.24.43) joined #rest.
[08:32:08] jaminja (~jaminja@76.76.24.43) left irc: Changing host
[08:32:08] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[08:32:43] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove
[08:41:13] <darrelmiller> Morning mamund!
[08:41:49] <darrelmiller> I learned something new from Julien today.  Etags are specific to a representation, not a resource.  I did not expect that.
[08:42:06] <darrelmiller> I think I learn something new about HTTP every day.
[08:48:11] <mamund> darrelmiller: if you think about how the etag hash is created, it makes sense, too.
[08:48:28] <mamund> the XML representation will have a diff etag than the JSON representations of the same resource.
[08:50:32] <darrelmiller> Yeah, practically I can see how it is easier.  I just didn't think that was the meaning.
[08:50:59] <fumanchu> etags don't have to be a hash, iirc, that's just common usage?
[08:51:17] <mamund> fumanchu: correct
[08:51:25] <mamund> there is no standard for how an etag is gen'd
[08:51:47] <fumanchu> (but that's how we do it in cherrypy, too ;)
[08:51:57] <mamund> commonly it's a hash oc the contents (since that ensure diff etags for diff representations), but that's not a standard at all
[08:53:55] <darrelmiller> mamund: Hopefully there is no page counter in the representation :-)
[08:54:10] <mamund> LOL
[08:54:13] <mamund> doesn't matter
[08:54:26] <darrelmiller> why?
[08:54:41] <mamund> representations "in time" will all have diff etags - even for the same "resource" even for the same "page" of a "resource"
[08:55:17] <darrelmiller> but someone doing a GET is going to invalidate the ETag
[08:55:32] <mamund> not following?
[08:56:49] <darrelmiller> If your representation contains a page counter then each read is going to generate a different representation and therefore the ETag is different, and therefore it would never return 304.
[08:57:02] <mamund> ahh....
[08:57:13] <mamund> i see, you think that paging invalidates caching?
[08:57:34] <darrelmiller> no, different pages are different resources.
[08:57:49] <mamund> well, that's true whether you use etag or not, right?
[08:57:50] <fumanchu> he means a hit counter
[08:58:12] <darrelmiller> ahhh, I knew we were not talking about the same thing.
[08:58:20] <fumanchu> not pagination
[08:58:21] <darrelmiller> fumanchu: thanks for clearing that up!
[08:58:25] <mamund> aha!
[08:58:45] Action: mamund slap himself w/ a trout
[08:59:47] <mamund> ok
[09:18:05] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest.
[09:29:50] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[09:30:05] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Client Quit
[09:42:15] <whartung> Hump day all
[09:44:33] bigbluehat (~bigblueha@adsl-74-177-117-193.gsp.bellsouth.net) joined #rest.
[09:49:57] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[10:11:38] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[10:32:04] mephju (~mephju@dslb-094-222-010-037.pools.arcor-ip.net) left irc: Read error: Connection reset by peer
[10:43:09] <mamund> yo!
[10:43:26] Action: mamund is back from India Buffet<g>
[10:45:28] <darrelmiller> Indian food FTW.
[10:48:58] <whartung> meh, not a fan
[10:49:24] <mamund> was quite tasty<g>
[11:26:21] technoweenie (~technowee@host-86-220-9-69.midco.net) joined #rest.
[11:53:46] pc1oad1etter (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) joined #rest.
[12:10:12] <whartung> so, this is pretty cool... http://beagleboard.org/bone Little ARM SBC with an SD card running a Linux distro with node.js
[12:14:25] <mamund> whartung: this is like arduino?
[12:14:41] <whartung> no it's more powerful than an arduino
[12:15:36] <whartung> basically a tiny linux box
[12:16:00] <whartung> I've been eyeing the http://www.raspberrypi.org/
[12:16:25] <whartung> which will be a $35 ARM board. Supply a power supply, and plug in a USB hard drive.
[12:16:29] <whartung> itty bitty servers
[12:17:31] <mamund> cool
[12:17:41] <whartung> They're both around 700Mhz but what that really means I'm not sure.
[12:17:50] <whartung> but should be close to a Pentum 100-200Mhz machine
[12:21:16] <trygvis> the beagle board is very powerful
[12:21:44] <trygvis> your average smart phone run on either an 1GHz or 800MHz ARM
[12:24:37] <whartung> Back in the Day, Y2K, we ran the then "education.com" web site on a single Sparc 2 Ultra workstation with 512M of RAM. It was running Java, Tomcat, Apache, and Oracle. It ran "fine" and we had I think 100,000 people register on it in a short time.
[12:24:43] <trygvis> the raspberry pi is powerful enough to decode 1000p@30 video over hdmi
[12:25:08] <whartung> Now, I'd like to think that a Sparc 2 is faster than an ARM, but how much faster I can't say. and we have crappy drives back then as well
[12:25:20] <whartung> that's hardware doing that decoding tho trygvis 
[12:26:01] <whartung> so, anyway, I'd like to think these "little" ARM machine can actually serve quite a bit of traffic even with a USB based drive.
[12:26:42] <trygvis> it is :) http://osnews.com/story/25284/Calexda_s_New_Quad-core_ARM_Part_for_Cloud_Servers
[12:27:04] <trygvis> in particulary now that they're moving to "64 bits" too
[12:27:09] <whartung> yea, the new HP server
[12:29:30] <trygvis> they're really pushing intel now, I love it!
[12:29:52] <whartung> who, HP?
[12:29:53] <trygvis> but, bbl. time for some PowerPC based fun; PS3
[12:29:56] <trygvis> no, ARM
[12:30:08] <whartung> Alwyas get confused who ARM is :)
[12:30:19] <whartung> I thought ARM was Intel, or Intel did ARM or whatever lol
[12:31:25] <whartung> http://hardware.slashdot.org/story/11/11/02/0541235/hp-announces-arm-based-server-line
[12:39:10] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[13:03:18] <mamund> just found steve klabnik's twilio talk here:http://vimeo.com/30764565 
[13:03:39] <mamund> "Everything you know about REST is wrong"
[13:16:12] <pc1oad1etter> Playing it in the background now
[13:16:20] <mamund> same here
[13:16:21] <pc1oad1etter> Of course I already know that what i know is wrong.  :-)
[13:16:27] <mamund> LOL
[13:19:40] <mikekelly> :|
[13:22:48] <mikekelly> I really should write a solid post about how coming up with yet another custom media type for doing links and embedding shit is Not Doing REST(tm)
[13:24:16] <whartung> feel free to summarize it when you're done mamund 
[13:24:26] <mamund> ROFL
[13:24:49] <mikekelly> whartung: two words
[13:25:03] <mikekelly> hypermedia loldongs
[13:28:05] <mikekelly> erm
[13:28:46] <mikekelly> why do people always come up with their 'this is what REST is about' summaries of bullet points..
[13:29:02] <mikekelly> w
[13:29:03] <mikekelly> t
[13:29:04] <mikekelly> f
[13:29:14] <mamund> was that three bullet points?
[13:29:29] <mikekelly> Resources Representations Hypermedia
[13:29:36] <mamund> :)
[13:29:39] <mikekelly> oh wait
[13:29:42] <mikekelly> I see what you did there
[13:29:49] <mikekelly> I did there
[13:29:52] <mikekelly> we did there
[13:29:53] <mamund> !
[13:30:27] <mikekelly> caching - incredibly important
[13:30:39] <mikekelly> uniform interface - indredibly important
[13:30:55] <mikekelly> it's almost like when it was defined it shouuld've been defined as a style
[13:31:00] <mikekelly> as a set of constraints
[13:32:12] <mikekelly> its good to have someone like that who knows what they're talking about though
[13:32:37] <mikekelly> that twilio api is one of the better ones for sure
[13:33:14] <mikekelly> is it twilio that has the explorer thing?
[13:33:20] <mikekelly> or is that gowalla ?
[13:38:02] <whartung> youd think someone would write a paper about it by now...
[13:38:18] <mikekelly> lol
[13:38:22] <mikekelly> exactly
[13:38:46] <mikekelly> I think the best way any of us can really 'teach' people about rest is by not doing that at all and just doing stuff 'right'
[13:44:25] <mikekelly> this talk is actually pretty good
[13:44:33] <mikekelly> mamund: you still watching this ?
[13:44:39] <mamund> yep
[13:44:43] <mamund> he's doing Qs now
[13:46:42] <mikekelly> hm
[13:48:35] <mamund> tl;dnw ....
[13:49:14] <mamund> focus on resource, representations of them, and include hypermedia within them...
[13:49:35] <mamund> decent intro to the idea, gets a bit 'thin' toward the end.
[13:49:47] <mamund> steve is a good speaker i like what he's trying to do.
[13:50:02] <mamund> has the ear of the Ruby-ists and that's pretty cool.
[13:50:20] <mamund> worth a watch/listen, IMO.
[13:53:13] <mikekelly> mamund: yeah +1 about the reach of his voice
[13:53:27] <mikekelly> I'm writing a hal templating dsl for rails atm 
[13:53:34] <mikekelly> hoefully will get to open source it
[13:53:47] <mamund> hey, that's pretty cool.
[13:54:05] <mikekelly> yeah, essentially it's just a templating language for the V's in MVC
[13:54:18] <mikekelly> but it's based on the 'information model' of hal 
[13:54:25] <mikekelly> so you can render xml and json from it
[13:54:27] <mamund> makes sense
[13:55:47] <mikekelly> mamund: I think I remember talking to you about rails and having a problem with its routing dsl using 'resources' to really mean collection
[13:55:58] <mamund> huh
[13:56:00] <mamund> can't recall
[13:56:07] <mamund> that was proly a while back, right?
[13:56:17] <mikekelly> yeah
[13:56:19] Action: mamund is worried that he's gett too old to recall stuff
[14:02:49] <mikekelly> mamund: what do you think about soethin glike this:
[14:03:36] <mikekelly> <link rel="foo" href=".." depracated="2012-12-22" />
[14:03:58] <mamund> what does that rell me?
[14:04:33] <mikekelly> that should probably be deprecate rather than deprecated
[14:04:44] <mamund> LOL
[14:04:56] <mamund> this some "lifetime" info for the link?
[14:05:01] <mikekelly> right
[14:05:04] <mamund> ok
[14:05:23] <mikekelly> and also including some kind of semantic versioning attribute
[14:05:25] <mamund> servers are committed to supporting that link (and all it means) until data c
[14:05:27] <mamund> dat x
[14:05:34] <mikekelly> right
[14:05:58] <mamund> well, off hand, not sure i want to put that in the representation that clients might cache
[14:06:11] <mamund> but that might be no biggie
[14:06:24] <mikekelly> I thought about using URIs for the rels
[14:06:36] <mikekelly> and using Expires on the doc/schema at that URI
[14:06:44] <mamund> hmmm
[14:06:51] <mikekelly> but that doesn't seem particularly realistic
[14:07:06] <mamund> yeah, seems like a problem similar to RDf
[14:07:22] <mamund>  wher ids start to be treated as de-ref'able URIs
[14:07:29] <mamund> maybe not
[14:09:38] <mikekelly> yeah that is pretty much where I'm at
[14:10:08] <mikekelly> except I just don't want all the extra unnecessary shite associated with the rdf/semweb stuff
[14:10:44] <mamund> oh yeah, i agree
[14:10:51] <mamund> the point here...
[14:10:59] <mamund> is you want to tell clients something about the link, right?
[14:11:07] <mamund> so you can:
[14:11:13] <mamund> 1) do it within the body
[14:11:17] <mamund> 2) do it wihtin the headers
[14:11:35] <mamund> 3) do it wihting some linked resource (profile, rel-page, etc.)
[14:11:40] <mamund> 4) do it in OOB docs
[14:11:45] <mikekelly> right
[14:11:46] <mamund> that's about it, right?
[14:11:50] <mamund> :)
[14:12:01] <mamund> i've been leaning to 3) lately
[14:12:13] <mikekelly> ok so what about
[14:12:21] <mamund> working on adding a single ref to the rpresentation that points to a profile doc that is both human and machine-readable'
[14:12:24] <mamund> ??
[14:12:30] <mikekelly> <link rel=".." href=".." deprecation-warning=true />
[14:12:43] <mamund> hmmm
[14:12:55] <mikekelly> (as a client of my format if you encounter this you should write to your error log)
[14:12:59] <mamund> so now, no drop-dead date, just a warning that this link might go away?
[14:13:02] <mamund> be not suported?
[14:13:06] <mamund> change?
[14:13:17] <mikekelly> be removed
[14:13:26] <mamund> not just for this representation, but for all time?
[14:13:29] <mamund> all reps?
[14:13:37] <mikekelly> i.e. it's an old rel that's been superceded in some way
[14:13:44] <mamund> oh
[14:13:45] <mikekelly> by new rels implemented from breaking changes
[14:14:06] <mamund> "hey, stop using this one, use the other one that's in this representation"
[14:14:15] <mikekelly> more just a 
[14:14:28] <mikekelly> 'something bad is about to happen to you in teh future, write to your error log'
[14:14:29] <mamund> "and btw - tell your human keeper that this was marked bad and make that idiot update your code to stop looking at me:"
[14:14:36] <mikekelly> right
[14:14:38] <mamund> i see
[14:14:49] <mikekelly> having that baked into a generic interface might be useful ?
[14:14:58] <mikekelly> + and bit more pragmatic
[14:15:06] <pc1oad1etter> we have a teapot http status but no status for this situation?
[14:15:40] <mikekelly> I said ages ago we should have a 'begrudgingly accept' status code
[14:15:51] <pc1oad1etter> :-)
[14:18:03] <mikekelly> so which is more preferable.. doing that with a deprecation flag against the link or a status code from the target resource ?
[14:18:57] <mikekelly> I think it gets trickier with a status code if the linker and linkee resources are in different organisations
[14:19:47] <mikekelly> because if the linker wanted to deprecate a link they'd have to get the linkee to indicate to clients ont heir behalf
[14:20:12] <mikekelly> not sure how edge-case'y that is though..
[14:26:11] <mamund> sorry, was away
[14:26:59] <mamund> status code would be a 4x or 3x?
[14:28:02] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) left irc: Read error: Operation timed out
[14:28:40] <mikekelly> mamund: nah a 200
[14:28:53] <mikekelly> client didn't do anything wrong and request was successful
[14:29:26] <mikekelly> it's like a special case of 200 where you're telling the client it's going to break if it carries on
[14:29:34] <mikekelly> but the request itself was ok
[14:31:14] <mikekelly> this Tim Ewald talk is starting off pretty good
[14:37:00] <mikekelly> why did I leave it so long to watch this
[14:37:06] <mikekelly> doh :)
[14:37:09] <mamund> which talk is this?
[14:37:13] <mamund> infoQ?
[14:41:53] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) joined #rest.
[14:43:33] <mikekelly> mamund: yeah
[14:43:38] <mikekelly> hypermedi apis integration
[14:43:48] <mikekelly> hypermedia services for systems integration
[14:43:55] <mikekelly> crap title, solid talk so far
[14:43:59] <mamund> yeah, i think i watched hat a while back
[14:44:12] <mamund> yep
[14:44:15] <mikekelly> he's fuckign good at speaking too, whcih helps
[14:44:24] <mamund> knows his stuff *very* well
[14:44:45] <mikekelly> yeah for sure, I'm glad somene of his background shares my view on schemas :)
[14:44:52] <mamund> :)
[14:44:58] <mamund> which is?
[14:45:05] <mikekelly> Why Bother?
[14:45:37] <technoweenie> isn't that part of hypermedia though?  
[14:45:45] <technoweenie> a user agent can hit amazon.com and analyze forms to see what it can send
[14:46:08] <mikekelly> what are you validating with a schema ?
[14:46:18] <technoweenie> i suppose you'd just do that in your client logic.  rel "foobar" can send fields a and b
[14:46:54] <whartung> schema validation is an edge case where the processing time it takes to process a invalid payload is far higher than the cost of doing the actual valudation
[14:47:15] <mikekelly> hm
[14:47:15] <technoweenie> i'm not necessarily talking about validation though
[14:49:23] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove
[14:56:48] <mikekelly> technoweenie: does this templating langauge look interesting ? https://gist.github.com/9abeb5ad16424566dae1
[14:57:52] <mikekelly> that's likely what the templating language for hal will look like
[14:58:43] <technoweenie> template? whats that generate
[14:58:52] <whartung> thats looks neat
[14:58:55] <technoweenie> does that parse a hal response into a ruby object?
[14:59:10] <whartung> looks like it creates one
[14:59:11] <technoweenie> or does that generate hal from ruby objects
[14:59:20] <mikekelly> it generates a hal doc from model
[14:59:20] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Quit: bradley-holt
[14:59:25] <mikekelly> xml or json doesn't matter
[14:59:40] <whartung> so, being ruby ignoratn
[14:59:41] <technoweenie> personally i dont like instance eval.  what is resource being called on?  i cant really tell
[14:59:47] <technoweenie> but other then that nit pick, i like it
[15:00:15] <mikekelly> technoweenie: how would you do that otherwise?
[15:00:22] <whartung> how is that implemented. How does the "link" routine know about the surrounding "resource". DOes it look to a global stack or is it within a closure managed by the resrouce?
[15:00:33] <mikekelly> whartung: it's in a block
[15:00:40] <mikekelly> the do end block of the resource
[15:00:53] <whartung> the resource routine creates the block implcitly?
[15:01:20] <whartung> so, ruby has ways of embedding code in to othre routines?
[15:01:21] <mikekelly> blocks are first class part of ruby
[15:01:39] <whartung> so, there's a "current block" primitive in ruby?
[15:01:51] <mikekelly> Procs
[15:02:11] <technoweenie> #resource would yield something i guess
[15:02:15] <whartung> can  you link the source of "resrouce" real quick for me to look at?
[15:02:20] <technoweenie> blocks are closures
[15:02:27] <mikekelly> whartung: I can't it's an internal project atm
[15:02:32] <whartung> ok
[15:02:37] <mikekelly> that gist is private -_-
[15:02:42] <mikekelly> was private
[15:02:43] <mikekelly> :)
[15:02:55] <technoweenie> mikekelly: have you seen my sawyer project?  i think that could be made to read HAL pretty easily
[15:03:02] <technoweenie> are you working on reading HAL yet
[15:03:13] <mikekelly> no that's next
[15:03:25] <mikekelly> possibly
[15:03:32] <mikekelly> maybe not we're not consuming our own service :)
[15:03:36] <technoweenie> oh ok
[15:03:51] <technoweenie> well sawyer consumes my HAL-like JSON example
[15:04:12] <mikekelly> yeah I did see it the other day I just havent had time to look at it properly
[15:04:18] <mikekelly> have you seen the restfulie stuff ?
[15:04:26] <technoweenie> no
[15:04:35] <mikekelly> restuflie is pretty interesting
[15:04:50] <technoweenie> its massive, wow
[15:05:08] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[15:05:17] <whartung> so  "yield" invokes a block?
[15:05:49] <technoweenie> mikekelly: yea this looks really similar
[15:06:09] <mikekelly> technoweenie: the guys who run that project are awesome
[15:06:33] <mikekelly> whartung: yeah it does
[15:06:44] <technoweenie> i'm gonna start on an official github client tomorrow
[15:06:49] <whartung> ok I sorta see how this works.
[15:07:11] <mikekelly> whartung: the idea is that dsl is recursive 
[15:07:20] <whartung> sure
[15:07:36] <mikekelly> technoweenie: were you saying there's a cleaner way to do that dsl ?
[15:07:41] <whartung> I was just curious how the interior code was populating the hidden datastructure, and how it sees it
[15:07:52] <technoweenie> mikekelly: it looks pretty good.... i just dont like instance_eval
[15:07:53] <mikekelly> technoweenie: did you mean like the way builder works ?
[15:08:00] <technoweenie> i like blocks yielding objects
[15:08:06] <technoweenie> i dont like self changing
[15:08:11] <technoweenie> but do what you like :)
[15:08:15] <mikekelly> lol
[15:08:23] <whartung> technoweenie isn't a very reflective person.
[15:08:28] <technoweenie> i've written probably the worst ruby metaprogramming ever
[15:08:31] <mikekelly> did you just e-pat_me_on_the_head ?
[15:08:59] <mikekelly> I'm pretty sure you did.
[15:09:03] <technoweenie> lol
[15:09:37] <mikekelly> technoweenie: is there a good "this is why you don't want to do that" style articles I can read ?
[15:10:09] <technoweenie> not that i can think of
[15:10:31] <technoweenie> i'm not a conventional rubyist i guess
[15:10:39] <mikekelly> oh ok
[15:10:45] <mikekelly> so I'm swimming in the cool kid pool?
[15:10:57] <technoweenie> are you using cucumber 
[15:11:05] <whartung> is that what you call that thing floating in here?
[15:11:08] <mikekelly> .. no -_-
[15:11:25] <mikekelly> haha
[15:11:34] <mikekelly> i'm know for my floaters
[15:12:22] <mikekelly> right
[15:12:36] <mikekelly> time to sleep
[15:12:52] <mikekelly> night everyone - I'll ponder that advice technoweenie 
[15:13:16] <technoweenie> you could probably support both if you really wanted to by checking the blocks arity
[15:13:21] <mikekelly> it's not a complex dsl though, I dunno if that makes a difference
[15:13:49] <technoweenie> right
[15:14:35] <mikekelly> balls I want to quiz you more about this but I'd better shoot
[15:14:46] <mikekelly> might try and bug you about it at some point in the future if that's ok ? :))
[15:15:10] <mikekelly> gone.
[15:15:11] Action: mikekelly waves
[15:15:50] Action: mamund waves back
[15:29:08] <technoweenie> sure
[15:32:41] technoweenie (~technowee@host-86-220-9-69.midco.net) left irc: Remote host closed the connection
[15:37:20] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[16:05:33] superstructor (~isaac-smx@akl.smx.co.nz) joined #rest.
[16:11:37] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[16:54:56] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[17:00:09] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Computer has gone to sleep.
[17:15:37] Action: mamund is out
[17:45:00] bigbluehat (~bigblueha@adsl-74-177-117-193.gsp.bellsouth.net) left irc: Ping timeout: 240 seconds
[17:54:43] KevBurnsJr (~KevBurnsJ@50.0.103.39) left irc: 
[17:59:42] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 258 seconds
[18:07:01] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[18:09:27] bigbluehat (~bigblueha@adsl-74-177-83-221.gsp.bellsouth.net) joined #rest.
[18:47:57] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[19:52:38] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[19:58:04] bigbluehat (~bigblueha@adsl-74-177-83-221.gsp.bellsouth.net) left irc: Quit: Leaving.
[20:18:18] KevBurnsJr (~kevburnsj@c-67-169-94-104.hsd1.ca.comcast.net) joined #rest.
[20:35:47] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[20:50:19] KevBurnsJr (~kevburnsj@c-67-169-94-104.hsd1.ca.comcast.net) left irc: 
[22:02:43] superstructor (~isaac-smx@akl.smx.co.nz) left irc: Remote host closed the connection
[22:29:08] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[22:31:19] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Client Quit
[22:57:25] pc1oad1etter (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) left irc: Quit: pc1oad1etter
[23:13:34] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[23:16:16] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[23:16:16] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[23:16:16] Nick change: grove_ -> grove
[23:43:28] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[23:43:28] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[23:43:28] Nick change: grove_ -> grove
[00:00:00] --- Thu Nov  3 2011