#rest on irc.freenode.net 2011-11-02 (txt)

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