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

[00:14] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:15] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[00:15] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[00:15] grove_ -> grove
[00:43] ivanfi (~ivanfi@62.159.77.167) joined #rest.
[00:45] vmil86 (~vmil86@78.57.245.80) joined #rest.
[00:50] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:54] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[00:54] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[00:54] grove_ -> grove
[01:08] v-dogg (vmakinen@kapsi.fi) left irc: Ping timeout: 244 seconds
[01:14] v-dogg (vmakinen@kapsi.fi) joined #rest.
[02:00] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[02:00] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[02:00] grove_ -> grove
[02:24] <mikekelly> mamund: the roy post you linked to was saying "only start from a beginning"
[02:25] <mikekelly> steady state == entry point == beginning
[03:14] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) joined #rest.
[03:15] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) left irc: Client Quit
[03:15] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) joined #rest.
[03:16] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) left irc: Client Quit
[03:16] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) joined #rest.
[03:16] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) left irc: Client Quit
[03:17] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) joined #rest.
[03:33] <Jarda> yeah, I guess I could be used to HAL
[03:36] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[03:37] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[03:45] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[03:45] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[03:45] grove_ -> grove
[04:03] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) joined #rest.
[04:04] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[04:04] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[04:04] grove_ -> grove
[04:06] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[04:06] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[04:06] grove_ -> grove
[04:07] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[04:07] grove (~grove@aggw006.cappelendamm.no) left irc: Read error: Connection reset by peer
[04:07] grove_ -> grove
[04:20] mephju (~mephju@dslb-188-103-191-245.pools.arcor-ip.net) joined #rest.
[04:41] <mikekelly> Jarda: you like hal or.. ?
[04:41] VSpike (~johncc@host217-41-3-16.in-addr.btopenworld.com) left #rest ("WeeChat 0.3.5").
[05:01] <Jarda> mikekelly: I guess. It's just a bit weird to use objects instead of arrays for collections
[05:01] <Jarda> and the notation is kinda weird coming from xml
[05:22] <darrel> jarda: Why not use the XML variant of hal?
[05:23] <Jarda> darrel: currently I'm working on a browser web app
[05:23] <Jarda> and the technologies work easier with json
[05:23] <darrel> ahhh yes, the browser straitjacket. :-)
[05:25] <Jarda> I know I can use xml also
[05:25] <Jarda> I just would need to write more parsing code
[05:59] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[06:01] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest.
[06:06] <mikekelly> Jarda: the problem with using arrays for a collection is the obvious - you have 0 ability to express links and/or embed resources other than items
[06:08] <Jarda> mikekelly: yeah I get it
[06:08] <mikekelly> if you commit to doing that you could find yourself in difficult situation in the future
[06:08] <mikekelly> using Link headers etc
[06:10] sbanwart (~sbanwart@h137.75.189.173.dynamic.ip.windstream.net) joined #rest.
[06:13] <mikekelly> darrel: you liked that semantic-fu earlier ? :D
[06:16] <darrel> :-) You've been reading too many I-Ds
[06:16] <darrel> or spending too much time on rest-discuss
[06:17] <darrel> soon you are going to feel that you MUST capitalize words that SHOULD not need to be.
[06:31] <mikekelly> haha
[06:34] sbanwart (~sbanwart@h137.75.189.173.dynamic.ip.windstream.net) left irc: Ping timeout: 245 seconds
[06:50] <gchristensen> mikekelly: can you elaborate on that? re: using arrays for collections
[06:51] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove
[06:52] mamund slides by
[06:52] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Quit: Leaving.
[07:00] <mikekelly> gchristensen: an array can't have any properties of it's own other than its containing items
[07:00] <mikekelly> i.e. you're creating a resource that is incapable of representing its own state
[07:01] <gchristensen> ah, ok
[07:01] <mikekelly> which is fine when you have a simplistic interpretation of a collection
[07:01] <mikekelly> but collection resources almost always outgrow that model
[07:01] <mikekelly> e.g. pagination links etc.
[07:05] <gchristensen> makes sense. I appreciate it!
[07:06] <mikekelly> cool, np
[07:17] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest.
[07:35] sbanwart (~sbanwart@h137.75.189.173.dynamic.ip.windstream.net) joined #rest.
[07:38] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[07:40] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Client Quit
[07:51] twilliams_ (41decaca@gateway/web/freenode/ip.65.222.202.202) joined #rest.
[07:51] tomayac_ (~tomayac@213.61.101.1) joined #rest.
[07:52] <twilliams_> g'mornin all, is this still the state of the art in thinking about versioning?
[07:52] <twilliams_> http://www.stucharlton.com/blog/archives/000589.html
[07:53] <mikekelly> twilliams_: did you see mnot's post ?
[07:53] <mamund> twilliams: i've been working on a diff POV in the last year or so
[07:54] <mamund> more along the lines of mnot's post
[07:54] <twilliams_> i thought there was a more recent one
[07:54] twilliams_ scurries off to google
[07:57] <mamund> in a nutshell, my POV is use "extending" to make _compatible_ changes, using "Versioning" to make _breaking_ changes; make sure client and server plan ahead for both.
[07:57] <mikekelly> common sense, basically
[07:57] <mamund> :)
[07:58] <Ngarthl> mamund: +1 :)
[07:58] <mikekelly> at least most people have stopped talking about forms.
[07:58] <Ngarthl> fooooorms, foooorms :P
[07:58] <mamund> f*****
[07:58] <twilliams_> right, thanks @mamund, i think the challenge is once you choose to have a breaking "versioning" what's the 'best' way to do it
[07:58] <mamund> the new "F" word
[07:59] <mamund> twilliams: _I_ use a new media type<g>
[07:59] <mikekelly> I really should respond to that asanine post from seb
[07:59] <mikekelly> just can't be bothered on teh basis that he clearly didn't read what I wrote first time
[07:59] <twilliams_> i've grown to hate versioning-via-uri but can't recall why exactly
[07:59] <mamund> mikekelly: fool rush in...
[07:59] <mamund> twilliams: v-by-uri can be seen as "cruft"
[08:00] <mamund> IMO, it's not a big deal. new "resource" needs a new uri.
[08:00] <mikekelly> in practice versioning by link rel is versioning by uri
[08:00] <mamund> adding /v1/ to _all_ the URIs in some namespace is a PITA
[08:00] <mikekelly> it's just a much better way of communicating the change
[08:00] <mamund> esp when just a couple reources change, many will add /v1.1/ to _all_ the URIs again.
[08:01] <mamund> but i don't get too excited about it<g>
[08:01] <twilliams_> cool, thanks gents
[08:01] <mamund> after all, they're URIs!
[08:01] <mamund> :)
[08:01] <twilliams_> going in position, is don't then:)
[08:01] <mikekelly> mamund: well that's not strictly true.. you don't necessarily have to move all the resources
[08:01] <twilliams_> where are the archives, btw?
[08:01] <twilliams_> for the channel?
[08:01] <mamund> right, you don't need to move hardly any of them in most cases.
[08:02] <mikekelly> rest.hacketyhack.net
[08:02] <mamund> LOL
[08:03] <mamund> http://rest.hackyhack.net/
[08:03] <mikekelly> that's the one
[08:03] <mamund> KevBurnsJr maintains the archives for us
[08:03] <mikekelly> HAIL KEV
[08:04] <mamund> *Hail*
[08:04] <mikekelly> mamund: did you read through that forms thread thing
[08:04] <mamund> kept an eye on it, steered clear of the fray<g>
[08:05] <mikekelly> it ended up with seb basically agreeing with me but telling me we disagreed
[08:05] <twilliams_> cool, who has the karma necessary to change the channel subject to include a linky to the archives? :)
[08:05] <mikekelly> mamund is an @orator
[08:05] <mamund> LOL, i'll update the header shortly.
[08:05] <twilliams_> HAIL mamund too
[08:09] Topic changed on #rest by mamund!mamund@69.163.32.100: REpresentational State Transfer | Archives: http://rest.hackyhack.net | http://tech.groups.yahoo.com/group/rest-discuss | http://code.google.com/p/implementing-rest/ | http://en.wikipedia.org/wiki/Representational_State_Transfer
[08:10] mamund has updated the topic of the channel (skilz!)
[08:10] <fumanchu> dangit, I thought this was the REStructured Text channel!
[08:11] <fumanchu> :P
[08:12] <mamund> :)
[08:14] <mikekelly> did I mention how much of a waste of time forms are ?
[08:15] <mamund> no, tell me more...
[08:15] <mikekelly> :)
[08:17] <mamund> :)
[08:23] <mikekelly> http://tech.groups.yahoo.com/group/rest-discuss/message/17910
[08:23] <mikekelly> yeah cool
[08:24] <mikekelly> don't bother reading my posts - just imagine whatever you like and attack that
[08:25] <mikekelly> WINNING
[08:26] <mikekelly> Depending on your scenario that cost may be justified or not. (no shit)
[08:28] sbanwart (~sbanwart@h137.75.189.173.dynamic.ip.windstream.net) left irc: Ping timeout: 276 seconds
[08:37] <mamund> YMMV, eh?
[08:38] <mikekelly> yeah, my problem is that doesn't contradict what I said
[08:41] <mikekelly> and omits a practical example where that would make sense
[08:41] <mikekelly> bar talking about HTML which is irrelevant
[08:43] <mamund> mikekelly: from my POV, this boils down to impl. details and "justification"
[08:44] <mamund> i am just starting to actually try _write_ non-trivial examples of m2m apps that rely on some kind of "form construct"
[08:45] <mamund> right now, i would say it's too early for me to make any defensible claims about how much "better" or "worse" they "are" over...
[08:45] <mamund> the HAL-style of defining them "out-of-band"
[08:45] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[08:45] <mamund> IMO, we just need clear evidence, examples, etc. to suss this out more
[08:46] <mamund> my _assumption_ is (for M2M) that there is no appreciable diff (IOW, no clear benefit for either case), but that's all assumption.
[08:46] <mamund> FWIW, subbu talked at the last RESTFest about using "ilities" to justify arch choices...
[08:47] <mamund> but did not provide any "process/methodology" or measurement for doing that
[08:47] <mamund> i think this form/oob thing falls near the same pit; we don't have good ways to measure this stuff right now.
[08:48] mamund steps off his soap box and walks to his seat
[08:48] <whartung> the primary value of a form submission is for a high level client being able to respond better to a lower level server
[08:48] <whartung> arguably this is a versioning problem
[08:49] <whartung> but the basic premise is to consider the navigation and reader task for an application
[08:49] <whartung> these artifacts are published via links in the hypermedia. And the client must know what the rels mean so that it can choose its links
[08:49] <whartung> it MAY also have the opportunity to take a different path trhough an application based on what links are made available
[08:50] <whartung> the classic example of that is if you had v1 of of a service that had a 3 step process to perform something, started with rel "procA", but later, optimized it to be more efficient and labeled that rel with "procB".
[08:51] <whartung> If the client encountered a service that only supported "procA", then that's the choice it's forced to make. But since this client also supports "procB" then if it encountered that AS WELL as "procA", it would choose that path
[08:52] <whartung> the "procA" is still made available for perhaps other use cases, or for older, v1 clients. But the "procB" is there for v2 clients.
[08:52] <whartung> Now consider the same aspect with a form
[08:52] <whartung> a form allows the server to publish that it supports these data elements for input
[08:53] <whartung> as the needs change, it can add more elements to that form, allowing compliant clients to fill in those extra elements (perhaps skipping older elements) as the service and clients evolved.
[08:53] <mikekelly> don't most servers just ignore parameters that aren't of any use ?
[08:53] <mikekelly> that seems a lot easier solution than asking clients to nob about with forms
[08:53] <whartung> This could also be done solely through the rel, and without any kind of form whatsoever (the specification being adverstised out of band)
[08:54] <whartung> servers can do whatever they want with forms. But to that note, I think it's fair that if a server PRE-POPULATES a form field, the client should be obliged to "echo" that value back if it chooses not to change it.
[08:54] <whartung> even for fields the client does not understand
[08:55] <mikekelly> huge security implications
[08:55] <whartung> oh I don't think so. You still have to check all this stuf on the server, that rule doesn't change.
[08:55] <whartung> consider in programming lanaguages where you have some that support function with optional, but default parameters.
[08:56] <mikekelly> for the client I mean
[08:56] <whartung> sometimes you can take an existing function, add some optional params and be backward compatible with existing uses while enable new uses.
[08:56] <whartung> how so?
[08:57] <mikekelly> you're asking them to offload the integrity of their client interactions to you (a third party)
[08:57] <whartung> by returning a value that they sent you?
[08:57] <mikekelly> that wouldnt' even fly in some intra-organisation stuff
[08:57] <mikekelly> yeah that's integrity
[08:59] <mikekelly> in practice that's only useful in a situation where you are being 'offloaded' as a client from one organisation to another who don't share the info
[09:00] <mikekelly> I'm pretty sure any security wonk will get his knickers in a twist about that
[09:03] <whartung> so youre suggesting that the client gets a form from service A and will then submit that form to service B?
[09:06] <mikekelly> that's what you're suggesting, right ?
[09:07] <whartung> I've not considered cross domain applications like that, no
[09:08] <whartung> it was more as part of the HM containing FORMs for their own services. How would Service A know what to send Service B?
[09:08] <mikekelly> I have no idea
[09:08] <mikekelly> why would service A want a client to tell it stuff it already knows
[09:08] <mikekelly> ?
[09:09] <whartung> you mean pre-filled form fields?
[09:09] <mikekelly> also, not using forms doesn't mean you can't have an application in which certain resource states are used to compose other requests..
[09:10] <mikekelly> it just means they aren't "dynamic" and in band
[09:11] <whartung> I'm only suggesting the use of forms as a mechanism for the service to publish what it supports as input in an in band way.
[09:11] <mikekelly> what does it buy you to have that in band?
[09:13] <whartung> It lets clients that support that new information know that the service accepts it, because it's asking for it. If the service doesn't ask for it, then the client can assume it doesn't want this extra information. Old clients would ignore the new fields, since they don't know what they are, new clients would fill them in because the service is asking for them and the client does know how to populate them, yet if the client were to talk to
[09:13] <whartung> older service that is not yet asking for this information, it would simply populate the old fields like the oringinal older client did.
[09:14] <mikekelly> but machine clients don't write themselves
[09:14] <mikekelly> people write them
[09:14] <whartung> of course
[09:14] <mikekelly> so having them 'in band' makes no odds
[09:14] <whartung> but the goal is to allow the clients and server to ideally evolve at a separate rate of sophistication and functionality.
[09:15] <mikekelly> wait what?
[09:15] <whartung> it can also be managed by simply returning version informatiion. It's simply a different mechanism for a service to publish what version of the service it is supporting.
[09:15] <mikekelly> you can make non-breaking changes to interactions based on out of band info
[09:15] <whartung> of course you can
[09:15] <mikekelly> so it doesn't buy you that
[09:15] <mikekelly> it's just another (more complicated way) of achieving basically the same thing
[09:16] <whartung> to me, it's all about versioning the service and the clients. There are other mechanisms to publish version information.
[09:16] <Ngarthl> complicated perhaps, but simpler.
[09:17] <Ngarthl> http://www.infoq.com/presentations/Simple-Made-Easy <- everyone should see this ;)
[09:17] <mikekelly> I don't think forms are a simpler interaction model than following links in a pre-defiend fashion
[09:18] <whartung> you're still following the links, none of that has changed. all the forms do is allow the specifiation to included in band.
[09:18] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[09:18] <mikekelly> right
[09:18] <mikekelly> but in band to machien clients
[09:18] <whartung> of course
[09:19] <mikekelly> who aren't the agent of change
[09:19] <whartung> like I said
[09:19] <mikekelly> peolpe are the agent of change
[09:19] <whartung> but they can support mutliple verions
[09:20] <whartung> machine client A support V1 of a protocol. Client B supports V2
[09:20] <mikekelly> why is that exclusive to forms ?
[09:20] <whartung> it's not
[09:20] <mikekelly> ..
[09:20] <mikekelly> lol :D
[09:20] <whartung> The forms are an ALTERNATE WAY for a service to publish VERSION information
[09:21] <mikekelly> I understand that, my question is - why would anyone want to use this alternative (more costly) way of doing thing
[09:21] <mikekelly> I can turn right 270 degrees
[09:21] <mikekelly> instead of turning left 90
[09:21] <mikekelly> I know which one I'd rather do on a regular basis
[09:22] <whartung> What is your favored mechanism of versioning?
[09:22] <mikekelly> if it's a breaking change create a new link relation
[09:22] <twilliams_> one appealing capability of forms is that they allow the server to constrain the choices of a particular parameter
[09:22] <mikekelly> if it's not breaking just make the change out of band in the doc
[09:22] <mikekelly> that's teh point of a non-breaking change
[09:22] <twilliams_> i haven't seen a way to do that with uri-templates
[09:23] <twilliams_> but then, i'm not following uri-templates that closely
[09:23] <mikekelly> twilliams_: why could that not just be a resource interaction?
[09:23] <mikekelly> link rel="option"
[09:23] <mikekelly> link rel="options"
[09:24] <mikekelly> link rel="options" href="/activity/123/options"
[09:24] <twilliams_> i suppose it *could* be; only forms inherently supports it vs. having to mint some new media type + link relations
[09:25] <mikekelly> link relations are good that's what your app should consist of
[09:25] <twilliams_> true, they do, mostly
[09:26] <mikekelly> it's hard enough to get people to use link rels or URI templates
[09:27] <mikekelly> introducing Yet Another Annoying Rest Thing I Don't Understand Why I'm Doing will probably tip people over the edge
[09:27] <mikekelly> I'm worried about Roy's safety, at the end of the day
[09:27] <twilliams_> huh? i don't understand
[09:28] <mikekelly> I mean if you write a nice hypermeida application
[09:28] <mikekelly> with link rels
[09:28] <mikekelly> but some dickhead is like "why am I following rels? I can just take the id and append it to "/widget/" and I get there anyway"
[09:29] <mikekelly> or you create a URI template and someone treats it in a similar fashion
[09:29] <mikekelly> it's hard enough to convince/prevent people doing that
[09:30] <mikekelly> which makes me doubt how realistic it is to get people to use forms, even if they were worth the effort
[09:31] <twilliams_> weird, is your argument that a) forms aren't good; or b) people aren't smart enough to use them ?
[09:31] <darrel> Link relations are media type agnostic. At the moment forms only really exist in HTML. That's by far the most compelling reason not to use them :-)
[09:31] <mikekelly> twilliams_: my argument is that forms aren't good enough to warrant their cost
[09:32] <mikekelly> to the client in terms of additional complexity
[09:34] <whartung> I guess the point is simply that even if only documented out of band, a client may not know what version a specific server is supporting. Your premise of "don't most servers ignore extra parameters anyway" suggests that the client send the latest version is supports to all servers and not worry about which version the server supports.
[09:34] mamund whacks darrel w/ a fish
[09:34] ivanfi (~ivanfi@62.159.77.167) left irc: Quit: Leaving.
[09:34] <twilliams_> http://tech.dir.groups.yahoo.com/group/rest-discuss/message/13615
[09:35] NOKAH (~hakon1@228.136.16.62.customer.cdi.no) joined #rest.
[09:35] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) left irc: Read error: Connection reset by peer
[09:35] <mikekelly> whartung: exactly
[09:35] <mikekelly> why would that approach be a problem ?
[09:36] <twilliams_> i'd asked it another way here:
[09:36] <twilliams_> http://tech.dir.groups.yahoo.com/group/rest-discuss/message/12710
[09:36] bigbluehat (~bigblueha@adsl-98-71-147-78.gsp.bellsouth.net) joined #rest.
[09:36] <whartung> it likely wouldn't. But it's good to be aware of the "ignore parameters" detail up front as a service design constraint, particularly in things like PHP and such.
[09:37] NOKAH (~hakon1@228.136.16.62.customer.cdi.no) left irc: Read error: Connection reset by peer
[09:37] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) joined #rest.
[09:37] <mikekelly> afaik that's pretty much how php will behave anyway
[09:37] tomayac_ (~tomayac@213.61.101.1) left irc: Quit: tomayac_
[09:38] <mikekelly> most php frameworks
[09:38] <whartung> I thought it bound all of the parameters in to the space automagically
[09:38] <whartung> I don't know much about PHP
[09:38] <mikekelly> right, but most frameworks if you chuck parameters into a model will just use the params which are relevant and leave the rest
[09:39] <mikekelly> rails creates a hash from the params and you just pass it into the model like User.new(params[:user])
[09:39] <whartung> yea
[09:39] <mikekelly> it's trivial to deal with server side
[09:39] <mikekelly> and it means you aren't creating a boundary to adoption for your clients
[09:39] <whartung> the only thing in PHP (as I understand it) is if a param is the same name as a variable, its possible that the param will overwrite the variable, yes?
[09:40] <whartung> I'm just saying they need to be conscious of it, not saying it's difficult to deal with
[09:40] <mikekelly> huh?
[09:40] <mikekelly> right
[09:41] <mikekelly> so the option is 1. deal with it on the server side or 2 require my clients to handle and correctly deal with dynamic forms in band
[09:42] <whartung> my only point there is that dealing with dynamic forms doesn't seem that big of a leap over dealing with dynamic rels anyway.
[09:42] <mikekelly> multiple rels not dynamic rels
[09:42] <mikekelly> a breaking change is a new link (in parallel)
[09:52] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest.
[11:36] bigbluehat (~bigblueha@adsl-98-71-147-78.gsp.bellsouth.net) left irc: Quit: Leaving.
[12:11] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Quit: bradley-holt
[12:22] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest.
[13:24] twilliams_ (41decaca@gateway/web/freenode/ip.65.222.202.202) left irc: Quit: Page closed
[13:57] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[14:36] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[14:41] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[14:45] technoweenie (~technowee@host-86-220-9-69.midco.net) joined #rest.
[14:45] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove
[15:12] jaminja (~jaminja@76.76.24.43) joined #rest.
[15:12] jaminja (~jaminja@76.76.24.43) left irc: Changing host
[15:12] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[15:16] mamund is done for the day, adios!
[15:39] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Quit: bradley-holt
[16:21] mephju (~mephju@dslb-188-103-191-245.pools.arcor-ip.net) left irc: Read error: Connection reset by peer
[17:14] KevBurnsJr (~KevBurnsJ@50.0.103.39) left irc:
[17:49] vmil86 (~vmil86@78.57.245.80) left irc: Remote host closed the connection
[18:29] bigbluehat (~bigblueha@adsl-98-71-147-78.gsp.bellsouth.net) joined #rest.
[18:49] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[18:51] KevBurnsJr (~kevburnsj@c-67-169-94-104.hsd1.ca.comcast.net) joined #rest.
[19:27] darrelmiller (~darrelmil@bas3-montreal50-1177637007.dsl.bell.ca) joined #rest.
[19:29] darrel (~darrelmil@bas3-montreal50-1177637007.dsl.bell.ca) left irc: Ping timeout: 252 seconds
[20:04] Wombert (~Wombert@dslb-092-075-024-076.pools.arcor-ip.net) left irc: Quit: Wombert
[20:35] technoweenie (~technowee@host-86-220-9-69.midco.net) left irc: Remote host closed the connection
[21:23] bigbluehat (~bigblueha@adsl-98-71-147-78.gsp.bellsouth.net) left irc: Quit: Leaving.
[21:54] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 240 seconds
[22:03] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[23:01] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 260 seconds
[23:21] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[00:00] --- Wed Nov 2 2011