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

[00:00] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Quit: quest88
[00:22] nuclearsandwich (~nuclearsa@74-93-3-241-SFBA.hfc.comcastbusiness.net) left irc: Remote host closed the connection
[00:24] nuclearsandwich (~nuclearsa@74-93-3-241-SFBA.hfc.comcastbusiness.net) joined #rest.
[00:25] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[00:51] ssedano (~ssedano@unaffiliated/ssedano) joined #rest.
[02:21] nuclearsandwich (~nuclearsa@74-93-3-241-SFBA.hfc.comcastbusiness.net) left irc: Remote host closed the connection
[03:18] Wombert (~Wombert@dslb-092-075-018-142.pools.arcor-ip.net) joined #rest.
[05:07] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[05:26] Wombert_ (~Wombert@dslb-092-075-028-008.pools.arcor-ip.net) joined #rest.
[05:28] Wombert (~Wombert@dslb-092-075-018-142.pools.arcor-ip.net) left irc: Ping timeout: 240 seconds
[05:28] Wombert_ -> Wombert
[05:45] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest.
[05:49] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[05:54] Wombert_ (~Wombert@dslb-092-075-026-221.pools.arcor-ip.net) joined #rest.
[05:57] Wombert (~Wombert@dslb-092-075-028-008.pools.arcor-ip.net) left irc: Ping timeout: 252 seconds
[05:57] Wombert_ -> Wombert
[06:13] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Ping timeout: 248 seconds
[06:13] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[06:18] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[06:34] nuclearsandwich (~nuclearsa@43.sub-166-250-33.myvzw.com) joined #rest.
[06:39] Wombert_ (~Wombert@dslb-088-065-196-070.pools.arcor-ip.net) joined #rest.
[06:41] Wombert (~Wombert@dslb-092-075-026-221.pools.arcor-ip.net) left irc: Ping timeout: 248 seconds
[06:41] Wombert_ -> Wombert
[06:41] nuclearsandwich (~nuclearsa@43.sub-166-250-33.myvzw.com) left irc: Ping timeout: 252 seconds
[07:06] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove
[07:12] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[07:15] mamund shows up
[07:17] <mikekelly> :O
[07:18] <mamund> :)
[07:18] <mamund> mikekelly: you gonna answer Jakob's rest-discuss query?
[07:20] <mikekelly> er
[07:20] <mikekelly> which one was that ?
[07:20] <mikekelly> oh
[07:20] <mikekelly> hm
[07:21] <mamund> i am holding off on my version of the answer<g>
[07:21] <mikekelly> I just seem to repeat myself now
[07:21] <mikekelly> clearly nobody gives a shit what I think
[07:21] <mamund> giving you first crack at it <LOL>
[07:22] <mikekelly> mnot's post was pretty clear too
[07:22] <mikekelly> I don't think I can be clearer than that
[07:22] <mikekelly> the key thing for me is - make as few assumptions about the client as possible; because you don't control it
[07:22] <mikekelly> and if you do
[07:22] <mikekelly> I wouldn't worry about 'REST' too much
[07:23] <mikekelly> well you can if you want, depends on the scale of your organisation
[07:25] <mikekelly> the best you can do (imo) is define the semantics of your application on a standard media type (with link relations).. accept that clients will couple to those semantics.. and don't make breaking changes to the semantics
[07:25] <mikekelly> if you need to make breaking changes, create a new relation
[07:25] <mikekelly> anything else is not really worth the effort if you have a large client base
[07:26] <steveklabnik> morning all
[07:26] <mikekelly> herrrrooo
[07:45] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[07:47] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Client Quit
[07:49] <mamund> mikekelly: ok, my most verbose response to-date on H2M vs M2M is now posted to rest-discussion.
[07:49] <mamund> have at me!
[07:51] <steveklabnik> nice
[07:51] steveklabnik opens his email
[07:51] <mamund> this is the 'nub' of my current experimenting, still some hand-waving/speculation.
[07:51] <mamund> but i think i am on a decent path
[07:52] <steveklabnik> seems like a reasonable way to split it up
[07:53] <mamund> in my mind this helps sort it out...
[07:53] <mamund> one step at a time.
[07:53] <trygvis> I think there is a big difference in working with M2M vs H2M
[07:53] <mamund> been reading lots of usability and product design materials lattely
[07:53] <mamund> even some psychology on visual perception, inteaction in the environment, etc.
[07:53] <mamund> all been helping me sort out some ideas.
[08:01] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[08:08] Wombert_ (~Wombert@dslb-092-075-029-185.pools.arcor-ip.net) joined #rest.
[08:11] Wombert (~Wombert@dslb-088-065-196-070.pools.arcor-ip.net) left irc: Ping timeout: 255 seconds
[08:12] Wombert_ (~Wombert@dslb-092-075-029-185.pools.arcor-ip.net) left irc: Ping timeout: 244 seconds
[08:13] darrelmiller (~darrelmil@70.24.176.66) joined #rest.
[08:14] <mamund> trygvis: sorry i mised your comment. i, too, think there is a big diff...
[08:15] <mamund> what i have not yet decided on is whether this diff can be substantially mitigated using some design or implementation mods.
[08:15] <mamund> IOW, what steps, if any, can be taken to close the gap between H2M and M2M?
[08:16] <mamund> that's what i am experimenting w/ right now.
[08:16] Wombert (~Wombert@dslb-088-065-199-217.pools.arcor-ip.net) joined #rest.
[08:19] Wombert_ (~Wombert@dslb-088-066-204-157.pools.arcor-ip.net) joined #rest.
[08:20] axisys (~axisys@ip68-98-189-233.dc.dc.cox.net) joined #rest.
[08:21] Wombert (~Wombert@dslb-088-065-199-217.pools.arcor-ip.net) left irc: Ping timeout: 244 seconds
[08:23] Wombert_ (~Wombert@dslb-088-066-204-157.pools.arcor-ip.net) left irc: Ping timeout: 252 seconds
[08:26] Wombert (~Wombert@dslb-088-067-182-039.pools.arcor-ip.net) joined #rest.
[08:39] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Quit: Leaving.
[08:54] <trygvis> I though your answer to that was code on demand, in general at least
[08:54] <mamund> trygvis: right now, that's my answer.
[08:54] <mamund> but that may not be the only/best way.
[08:55] <mamund> there are cases where COD is not avail/supported.
[08:55] <mamund> and i think there are other options.
[08:55] <mamund> basically COD is the "domain knowledge" part
[08:55] <steveklabnik> it also adds cohesion, in that you have to have the right environment for that code...
[08:55] <mamund> and in current cases, this is supplied by the sever
[08:56] <mamund> steveklabnik: yes, and the COD is often specific for a client space.
[08:56] <mamund> what i want to do is see if there are other ways to supply this knowledge
[08:56] <mamund> possibly by employin the principle of the Uniform Interface
[08:56] <mamund> to the domain knowledge
[08:56] <steveklabnik> mm
[08:57] <mamund> not just the hypermedia affordances.
[08:57] <mamund> that's waht i'm exploring
[08:57] <mamund> now....
[08:57] mamund shudders a bit
[08:57] <mamund> this _may_ be leading to RDF as the uniform interface for "domain knowledge"
[08:57] <mamund> but i am not ready to go there yet
[08:57] <steveklabnik> hahahahah
[08:59] <mamund> :)
[08:59] <mamund> anyway, i am looking at the whole domain knowledge thing
[08:59] <mamund> and trying to "step back", "be creative", etc.
[08:59] <mamund> and see where it leads me (if anywhere<g>)
[09:08] <mamund> for example, i'd like to see the _client_ supply the COD, not the server.
[09:09] <mamund> this is common in desktop apps, but not browser apps.
[09:09] <mamund> it's like to see the client "alert" when new semantics (links, forms, etc.) appear in responses (maybe 'phone-home to mommma', etc.)
[09:11] <mamund> i'd like to see a more "universal" way to express domain-knowledge (not just JS or other executable code) so that the same "domain knowledge" could be shared with a wide range of user-agents
[09:11] <mamund> anyway, i ramble.
[09:16] <trygvis> UML?
[09:16] <trygvis> perhaps
[09:17] <trygvis> that's what I use when I whack the domain out of clients (the paying kind of clients, not the coded ones)
[09:17] <mamund> trygvis: i am thinking that this should be a runtime solution.
[09:18] <mamund> not that UML (or something like it) wouldn't do that, tho.
[09:19] <trygvis> I guess wsdl (which implies xsd) is the closes thing you a runtime version of uml you can get (other than the actual xml serialization of uml)
[09:20] <mamund> wsdl (IMO) doesn't communicate domain knowlege.
[09:20] <trygvis> people only assume WSDLs are something that you compile against once
[09:20] <mamund> wsdl is the possible actions (affordances)
[09:20] <mamund> wsdl doesn't offer _context_, tho (like _when_ it's ok to do this action for this user at this point in time, etc.)
[09:20] <trygvis> the XSD part does, people can agree on concepts and put them into a namespace
[09:20] <mamund> something wsdl-like, tho might do tht trick
[09:21] <trygvis> true, there's no context
[09:22] <trygvis> changing the subject, what happens with IETF drafts after they expire? they just lie there until someone potentially does something with it?
[09:22] <mamund> but your point is good. some external structured doc that is consumable _at_ _runtime_ that contains the details needed
[09:23] <mamund> yeah, they just sit
[09:23] <trygvis> like your draft-amundsen-item-and-collection-link-relations, is that just a way to get the relations registered with IANA?
[09:23] <mamund> yes
[09:23] <mamund> (i still need to submit a final for them to vote on)
[09:23] <trygvis> what happens after that vote passes?
[09:25] <mamund> it moves from I-D to RFC
[09:25] <mamund> gets a cute number, etc.
[09:26] <trygvis> hm, cool
[09:27] <mamund> will be "nice" to have an RFC in the pile w/ my name on it<g>
[09:27] <mamund> even such a minor one
[09:27] <mamund> it's been a very good experience, too.
[09:27] <trygvis> I would be prooud
[09:27] <mamund> yep
[09:29] <trygvis> I've been wondering if I should publish my little spec (which isn't small enough yet) to ietf, but I kinda doubt it's worth the trouble
[09:32] <mamund> trygvis: well, without knowing all the details, i would encouarge you to do it
[09:32] <mamund> again, it's a great learning experience
[09:32] <mamund> and you get to interact w/ some really smart folks!
[09:32] <trygvis> is there a playground? where I could ask someone if it's the kind of thing that's appropriate?
[09:33] <mamund> sure
[09:33] <trygvis> this is what I've been writing on: http://trygvis.dyndns.org/~trygvis/2011/11/drafts/html/
[09:33] mamund checks link
[09:33] <trygvis> it's not really ready for someone to read, it's still somewhere between a set of notes and a start of a specification
[09:34] <whartung> Hi all! o/
[09:35] <mamund> trygvis: i wonder which "list" this should go to....
[09:35] mamund waves to whartung '
[09:35] <mamund> trygvis: does IETF has apache or maven lists?
[09:35] <trygvis> I though all I-Ds went to apps
[09:35] <trygvis> not that I know of
[09:35] <whartung> why would IETF care about maven?
[09:35] <mamund> yeah
[09:35] <mamund> LOL
[09:35] <mamund> what would it care about apache?
[09:36] <whartung> yea that too
[09:36] <trygvis> the title actually doesn't cover the intent that much anymore
[09:36] <whartung> I didn't read it, is this a spec for REST operation on a maven repo?
[09:37] <trygvis> that was the original plan, but I see that it could be used for many kind of "artifact" repositories
[09:37] <trygvis> (maven define JARs, javadoc JARs, WSDLs etc as "artifacts")
[09:37] <whartung> well, how would it differ from something generic like WebDAV?
[09:38] <trygvis> there's a concept of a repository, artifacts are immutable. there's a way to search for them and a way to inspect attachments to artifacts (like POMs or signatures)
[09:38] <trygvis> maven already support webdav and see how nice that worked out :)
[09:39] <whartung> I don't know the history -- you've seen my vast experience with maven.
[09:39] <trygvis> I'm not saying it's a good idea to send it to IETF, I'm trying to figure out if it is
[09:39] <trygvis> and who to ask
[09:39] <mamund> fwiw, IETF is not the only place to go.
[09:39] <mamund> W3C hosts standards, too.
[09:39] <trygvis> as it is now I think the document is a bit overengineered
[09:40] <whartung> that's the thing -- seems fairly specific, not a piece of core infrastructure, that's all
[09:40] <trygvis> true, but I couldn't really figure out the process at w3c
[09:40] <whartung> well, hell, how about getting it accepted at Maven? :)
[09:40] <trygvis> that's true, it's fairly specific. is the purpose of ietf to focus on core stuff?
[09:41] <mamund> well, a number of "bindings" RFC exist
[09:41] <trygvis> I'm working at that too
[09:41] <mamund> can't say i understand their "level" tho
[09:41] <whartung> yea, there's bindings and profiles on top of generic standards
[09:41] <whartung> like you could say "to do a repo on top of WebDAV, do this...with these contraints and this organization"
[09:42] <mamund> the W3C has some packaging standards, too.
[09:42] <whartung> but yea I've always considered IETF to be basic plumbing
[09:42] <trygvis> whartung: that's sort of what I'm trying to do, it's just taking me a while to get there
[09:42] <whartung> which is why I itch that W3C wants to play with healthcare...
[09:43] <whartung> sure
[09:44] <whartung> frankly, what I would do is take one of the maven repo implementations and throw a REST section on it.
[09:44] <whartung> and then toy and work with that
[09:44] <whartung> and then document it out and see if there's any traction
[09:44] <whartung> standards made in a vacuum of use cases aren't really useful IMHO
[09:44] <trygvis> that's what I'm doing. I can actually publish to my repo with maven and ivy
[09:45] <whartung> ok good
[09:45] <whartung> so I would wave that banner and promote it in the maven community
[09:45] <whartung> let others break it and find gaps
[09:45] <whartung> let it mature
[09:45] <trygvis> I've done a *lot* of maven work the last 8 years or so, so I have a fairly good grasp of the use cases
[09:45] <whartung> sure
[09:45] <trygvis> which is why I started to put them in this document
[09:46] <whartung> basically, there's two kinds of standards.
[09:47] <trygvis> the ones that are used and the ones that aren't? :)
[09:47] <whartung> Actual standards, and de facto standards. Standards made by one entity are, imho, de facto, as they have not (necessarily) taken the input from the user space that would benefit from such a standard. A single implementation does not a standard make.
[09:47] <whartung> actual standards have the ying and yang and sausage making imperfections of folks trying to make it work.
[09:47] <whartung> committees, politics, etc.
[09:48] <whartung> consider the SQL standard for Web browsers. THey've given up, not because they don't have a standard, but because no one is willing to implement anything beyond embedding SQLite. And that's not a standard, it's an implementation.
[09:48] <whartung> so, now we have "no" standard for SQL in the browser, just a de facto hope that SQLite is bundled.
[09:49] <whartung> EJB is a Standard, Spring is an implementation
[09:49] <trygvis> yes, I see what you mean
[09:49] <whartung> not to disuade you from your efforts. I just think it will be better if it rises out of a more grassroots thing.
[09:50] <trygvis> and it's a good point about usage. so I'm implementing support in both ivy and maven at the same time
[09:50] <whartung> Consider two "competing" messaging standard in healthcare today.
[09:51] <whartung> One is the NwHIN standard, which is a large, complicated infrastructure with buy in by federal goverment and instituitions. It was a top down design, meetings and partners that, thankfully, consolidated in to a single shared implementation that all of the major players int he federal govt chose to use.
[09:52] <whartung> But many in the community found it very difficult, it's almost a SOAP v REST kind of thing.
[09:52] <whartung> So, the community rose up (with help from a sea chnage when the administration changed in Washington, which is stupid, IMHO but whatever)
[09:53] <whartung> and now we have a simpler standard that covers simply transport of data, rather than actual uses cases of document exchange and query.
[09:53] <whartung> And that's the DIRECT standard
[09:53] <whartung> as part of that effort, referenece implementations were promoted, and we have 2 now -- one for .NET and one for Java.
[09:54] <whartung> but it's all based on internet standards (SMTP, S/MIME, DNS, LDAP)
[09:54] <whartung> (there's that plumbing vs use case argument I used earlier about IETF)
[09:55] <whartung> so now we have implementations of both of these systems, avaliable to any one (all open source)
[09:55] <whartung> but also mandates for their use (notably from the federal govt)
[09:56] <whartung> So, group A found a need, and put a crap load of time and money in to a large, monolithic, cover-all-the-bases standard for exchange, and got buy in by the feds
[09:56] <whartung> the Rest of the World(tm) balked at the complexity, and fought back with a much simpler "transport only" standard
[09:56] <whartung> so, when you publish your REST work, we'll see how the community responds. They'll either embrace it or panic or ignore it
[09:57] <whartung> when someone asks to take your REST code to put in to their Repo implementation, you're moving forward. Otherwise, it's a nice feature of your system.
[09:57] <trygvis> yeah. most likely the latter, but hey. at least I'm hoping to learn something of the process on how to write this kind of specification
[09:57] <whartung> sure
[09:57] <whartung> that's a different issue :)
[09:58] <trygvis> but I am "connected" enough in the maven crowd so I can make it happen if I find the energy to do it
[09:58] <whartung> right
[09:58] <trygvis> where "make it happen" == "implement it in all the current implementations + maven"
[09:58] <whartung> you're not some whacko elbowing up to the bar and saying "look at me"
[09:59] <whartung> are you using java?
[09:59] <trygvis> actually I would just implement it in maven, my implementation and a set of client tools
[09:59] <trygvis> scala actually
[09:59] <trygvis> this is the code I've written so far: https://github.com/trygvis/artifact-repository
[09:59] <trygvis> (it's very much a work in progress just like the doc)
[10:00] <whartung> so, is the maven repository an actual server or is it just a structure on a HTTP server?
[10:00] <whartung> (in terms of what maven needs to get modules)
[10:00] <whartung> (whereas yo might have server side code to manage uploading of modules, but that's separate from the client view)
[10:00] <trygvis> both. I recognice the pattern that maven use to push stuff and redirect it to /upload
[10:01] <whartung> no, I mean the current mavenimplmentation
[10:01] <whartung> what they have now
[10:01] <whartung> you mentioned theres a couople of implementations of the repo as well
[10:01] <whartung> but I assume that maven comes with one, no?
[10:01] <trygvis> no, maven is just a client
[10:01] <whartung> and a repo is just a web server? that's all the maven client needs?
[10:02] <trygvis> in the early days maven just published to a webdav server
[10:02] <trygvis> almost, there are some files that maven expect to be available on the http server
[10:02] <trygvis> it uses the web server as a file system
[10:02] <whartung> right, it's a specific fiel hierarchy published on a generic web server
[10:03] <whartung> bah -- meeting...bbl
[10:03] <trygvis> field hierarchy + specific files with implicit meaning, yes
[10:03] <trygvis> here's an example: https://oss.sonatype.org/content/repositories/snapshots/org/codehaus/swizzle/swizzle-stream/1.0.3-SNAPSHOT/
[10:07] <trygvis> again I win by being on the right side of the lake
[10:08] trygvis puts his feed on the table and have another bit of the chocolate
[10:26] mamund is back from a late lunch
[10:31] bigbluehat (~bigblueha@adsl-74-177-96-212.gsp.bellsouth.net) joined #rest.
[10:32] _scott (~scott@78.129.202.63) left irc: Ping timeout: 244 seconds
[10:41] _scott (~scott@78.129.202.63) joined #rest.
[11:00] <Ngarthl> it's whisky o'clock
[11:00] <trygvis> woot woot
[11:02] <Ngarthl> feed on the table?
[11:02] mamund is jealous
[11:02] <Ngarthl> food? or feet?
[11:03] <whartung> he eats feet
[11:03] <trygvis> feet!
[11:03] nuclearsandwich (~nuclearsa@173.247.193.198) joined #rest.
[11:04] <nuclearsandwich> steveklabnik: batching. Can it work? Does it make sense?
[11:05] <trygvis> http://www.youtube.com/watch?v=qYodWEKCuGg
[11:05] Ngarthl is contemplating what to speak at the JUG come jan 11th. Practical REST ?
[11:05] <trygvis> hypermedia?
[11:06] <steveklabnik> nuclearsandwich: hey
[11:06] <steveklabnik> nuclearsandwich: can you elaborate on 'batching'?
[11:07] <nuclearsandwich> Multiple REST requests within a single network request.
[11:07] <steveklabnik> that doesnt make any sense.
[11:07] <steveklabnik> so no. :p
[11:07] <steveklabnik> unless someone in here knows more than me.
[11:07] <steveklabnik> now, if you mean 'batch operations,' like 'resize these 5 pictures,' that's something else
[11:08] <steveklabnik> is that what your'e asking?
[11:08] <trygvis> nuclearsandwich: each http message is supposed to be standalone
[11:08] <trygvis> however, I'll be generating tar files on the fly with my stuff so
[11:08] <nuclearsandwich> I'm talking about stuff like -> http://code.google.com/apis/youtube/2.0/developers_guide_protocol_batch_processing.html
[11:09] <nuclearsandwich> which both Facebook and Google keep insisting I use. Both are vendor specific methods of mimicking HTTP requests in some format, sending that, then getting all the responses back.
[11:09] <steveklabnik> sure. that's poor modelling
[11:09] <nuclearsandwich> I'm just curious if there's a right way and a wrong way
[11:09] <nuclearsandwich> or just wrong ways
[11:09] <nuclearsandwich> and wronger ways
[11:10] <steveklabnik> i gotta run
[11:10] <steveklabnik> we can talk about that later
[11:10] <nuclearsandwich> yeah, no worries. Catch ya later
[11:10] <whartung> all ways are wrong. Some ways are popular :)
[11:18] <mamund> nuclearsandwich: fwiw, in the (rare) cases where i need to handle multiple processing in a single request...
[11:18] <mamund> i craete a new resource just for that purpose.
[11:19] <mamund> and craft a state transition just for that purpose.
[11:19] <mamund> does that make sense?
[11:20] <mamund> subbu's book has some good examples of this, too.
[11:20] <mamund> http://my.safaribooksonline.com/book/web-development/web-services/9780596809140/miscellaneous-writes/203
[11:20] <mamund> http://my.safaribooksonline.com/book/web-development/web-services/9780596809140/miscellaneous-writes/206
[11:20] <mamund> and a couple others
[11:21] <mamund> (including a recipe on batch<!>)
[11:21] <nuclearsandwich> Cool, I'll check them out. I've got the REST Cookbook, but haven't had time to crack it open yet. Been making my way through REST in Practice.
[11:22] <mamund> that's a good book, too.
[11:22] <mamund> anyway, check out subbu's book for some good ideas on handing various bulk-type operations.
[11:39] <nuclearsandwich> thanks mamund, will do.
[11:40] <mamund> np
[11:40] <mamund> hope to see you hanging out here often
[11:52] <nuclearsandwich> yeah, didn't know this channel existed. I'll be lurking. :)
[11:52] <mamund> very cool'
[12:21] <steveklabnik> nuclearsandwich: okay, im' back
[12:21] <steveklabnik> so the thing that's really wrong about this is that it exemplifies an RPC approach
[12:21] <steveklabnik> and rest is not RPC.
[12:21] <steveklabnik> does that make any sense?
[12:22] <nuclearsandwich> yes, it does.
[12:23] <steveklabnik> so yeah, that's why mamund and i gave the 'make a new resource' answer. because that's what you're doing...
[12:23] <steveklabnik> also, half the answers to any given question about REST are 'make a new resource'
[12:23] <steveklabnik> heh
[12:23] <mamund> :)
[12:37] <nuclearsandwich> Okay, got it.
[12:38] <nuclearsandwich> How does that play with high latency environments? I've seen plenty of networks where fewer, larger payloads made sense
[12:38] <nuclearsandwich> I know I'm thinking too hard about the network and REST is an abstraction for design
[12:38] <steveklabnik> you're still approaching it from an rpc angle.
[12:39] <nuclearsandwich> just curious if that's ever been an issue.
[12:39] <steveklabnik> if you want to chunk, use chunked encoding.
[12:39] <nuclearsandwich> hmm
[12:40] <nuclearsandwich> I amwill understand..
[12:40] <steveklabnik> REST is poor for _low_ latency environments
[12:40] <steveklabnik> anyway, i'm stepping out again for another bit.
[12:40] <nuclearsandwich> yeah, me too. Interested to hear more. I'm very much clueless but curious
[12:41] <nuclearsandwich> but right now it's grilled cheese and reading time!
[12:41] <trygvis> steveklabnik: I'd agree if this wasn't #rest
[12:41] <steveklabnik> trygvis: agree with what?
[12:41] <trygvis> that REST is poor with low latency systems
[12:41] <steveklabnik> ahh
[12:41] <steveklabnik> yeah, the web's architecture is not conducive
[12:42] steveklabnik shrugs
[12:42] <trygvis> SIP is one area where the systems use media types/formats for negotiation and signalling (signalling in the voip sense) and special protocols for the A/V streams
[12:43] <trygvis> we're also looking into making some embedded devices use at least some REST principles to configure themselves and figure out where to send messages
[12:59] Wombert (~Wombert@dslb-088-067-182-039.pools.arcor-ip.net) left irc: Quit: Wombert
[13:18] kevwilde (~kevwilde@igwe16.vub.ac.be) left irc: Ping timeout: 248 seconds
[13:18] kevwilde (~kevwilde@igwe16.vub.ac.be) joined #rest.
[13:26] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) left irc: Ping timeout: 240 seconds
[13:33] fu-manchu (~fumanchu@adsl-99-30-180-185.dsl.sfldmi.sbcglobal.net) left irc: Ping timeout: 245 seconds
[13:53] mamund is done for the week. toodles!
[13:54] <trygvis> later!
[14:06] scudco (~scudco@76-216-230-247.lightspeed.irvnca.sbcglobal.net) joined #rest.
[14:18] <nuclearsandwich> trygvis: that sounds interesting
[14:33] bigbluehat (~bigblueha@adsl-74-177-96-212.gsp.bellsouth.net) left irc: Quit: Leaving.
[14:43] <steveklabnik> nuclearsandwich: zomg back
[14:43] <nuclearsandwich> :D
[14:43] <nuclearsandwich> how's it going. I pondered the previous discourse, and think I get it.
[14:44] <steveklabnik> cool.
[15:16] scudco (~scudco@76-216-230-247.lightspeed.irvnca.sbcglobal.net) left irc: Ping timeout: 244 seconds
[15:16] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[15:23] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove
[15:46] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[15:46] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Client Quit
[15:57] fu-manchu (~fumanchu@adsl-99-30-180-185.dsl.sfldmi.sbcglobal.net) joined #rest.
[16:13] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) joined #rest.
[16:53] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) left irc: Ping timeout: 260 seconds
[16:59] nuclearsandwich (~nuclearsa@173.247.193.198) left irc: Read error: Connection reset by peer
[16:59] nuclearsandwich (~nuclearsa@173.247.193.198) joined #rest.
[17:05] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Remote host closed the connection
[17:54] nuclearsandwich (~nuclearsa@173.247.193.198) left irc: Remote host closed the connection
[18:15] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[18:28] Wombert (~Wombert@dslb-088-067-182-039.pools.arcor-ip.net) joined #rest.
[18:30] nuclearsandwich (~nuclearsa@70-36-236-91.dsl.static.sonic.net) joined #rest.
[18:31] nuclearsandwich (~nuclearsa@70-36-236-91.dsl.static.sonic.net) left irc: Remote host closed the connection
[19:15] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[19:23] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) joined #rest.
[19:34] ssedano (~ssedano@unaffiliated/ssedano) left irc: Ping timeout: 255 seconds
[19:36] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Ping timeout: 244 seconds
[19:37] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[21:31] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 252 seconds
[22:07] <bob_sage> which might be a good channel for apache wink
[22:27] bob_sage (~chatzilla@outbound4.ebay.com) left irc: Remote host closed the connection
[23:49] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Quit: quest88
[00:00] --- Sat Dec 3 2011