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

[00:11] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:11] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[00:40] darrelmiller (~darrelmil@bas1-montreal08-1279564619.dsl.bell.ca) left irc: Ping timeout: 252 seconds
[00:58] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:59] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit
[01:02] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) joined #rest.
[02:25] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Read error: Operation timed out
[02:32] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) left irc: Quit: brb
[03:03] zazi (~zazi@p579D3490.dip.t-dialin.net) joined #rest.
[03:15] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[03:15] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[05:17] darrelmiller (~darrelmil@76.65.142.100) joined #rest.
[05:21] <mikekelly> good morning resticles
[05:22] <darrelmiller> Ugh. Back to school day. Early... need more coffee.
[05:25] <mikekelly> oh cool darrelmiller, what are you studying ?
[05:25] <mikekelly> or are you still at the crayoning stage ?
[05:25] <mikekelly> no shame in that btw, crayon'ing is awesome
[05:25] <darrelmiller> Not for me. For the offspring. But, I had to pull the toboggan to school.
[05:26] <mikekelly> oh.
[05:26] Last message repeated 1 time(s).
[05:26] <darrelmiller> My kid likes to arrive in style.
[05:26] <mikekelly> pimp
[05:27] <darrelmiller> That would infer I get paid.
[05:28] <mikekelly> ha
[05:28] <mikekelly> so it's snowy up there at the moent
[05:28] <mikekelly> how long does that last ?
[05:29] <darrelmiller> It's been very mild so far this winter, usually we are snow covered in late november, this year it took until January. I expect to remain snow covered until early April.
[05:30] <darrelmiller> It's kinda cool when the snow piles in the parking lots get to 30-40 feet high.
[05:40] <mikekelly> lol that is just nuts..
[05:46] mephju (~mephju@dslb-188-102-111-180.pools.arcor-ip.net) joined #rest.
[05:49] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) joined #rest.
[05:52] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[05:54] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[05:54] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[06:04] bigbluehat (~bigblueha@adsl-74-177-98-159.gsp.bellsouth.net) joined #rest.
[06:09] mr_yall (~mr_yall@scifo.mexico86.co.uk) joined #rest.
[06:33] darrelmiller (~darrelmil@76.65.142.100) left irc: Ping timeout: 240 seconds
[06:54] mamund is here
[06:55] aGHz1 -> aGHz
[07:06] zazi_ (~zazi@p579D3490.dip.t-dialin.net) joined #rest.
[07:06] zazi (~zazi@p579D3490.dip.t-dialin.net) left irc: Ping timeout: 252 seconds
[07:07] zazi_ -> zazi
[07:09] <mikekelly> http://memegenerator.net/cache/images/300x/1/1125/1152667.jpg
[07:10] darrelmiller (~darrelmil@65.94.30.184) joined #rest.
[07:11] <mamund> is that for the 30-40 ft of snow?
[07:14] <bigbluehat> mamund: if you're bored my "Why CouchDB?" talk form Strange Loop is up: http://www.infoq.com/presentations/Why-CouchDB
[07:14] <mamund> will add it to my queue
[07:14] <mikekelly> isn't couchbase where it's at?
[07:14] <mikekelly> CouchBase: like CouchDB, but more fasterer.
[07:15] <darrelmiller> :-) I missed that link because my IRC client keeps dropping.
[07:15] <mikekelly> "A product and project with similar capabilities and goals, but more faster...."
[07:15] <mikekelly> That is not English.
[07:15] <mikekelly> it's either more fast, or faster.
[07:16] <mikekelly> it's not both.
[07:16] <mikekelly> fuck you Damien Katz.
[07:16] <darrelmiller> But english is a living language. It get's betterer with time.
[07:16] <mikekelly> that is all I took from his Couchbase article
[07:28] <bigbluehat> mikekelly: that post is Damien's position. It really should have been written as "The Future of CouchDB [for Damien Katz] is Couchbase"
[07:28] <bigbluehat> they're very different animals currently
[07:28] <mikekelly> right
[07:28] <mikekelly> read like a sales pitch
[07:28] <bigbluehat> and will likely remain that for some time
[07:29] <mikekelly> tbh I didn't really take it seriously after his 'more faster' gaff
[07:29] <mikekelly> yes I make mistakes like that all the time, but I'm disselectric so that's ok
[07:33] zazi (~zazi@p579D3490.dip.t-dialin.net) left irc: Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client
[07:38] <bigbluehat> mamund: don't get too famous…or this could happen to you: http://www.inicons.com/
[07:39] <mamund> LOL
[07:40] <darrelmiller> That's just creepy.
[07:40] <mamund> yep
[07:43] <darrelmiller> Ever have one of those days where you just don't want to work on what you are supposed to be working on. That's today!
[07:43] <fu-manchu> me too :/
[07:46] <mikekelly> media type meme thread was an utter failure.
[07:47] <darrelmiller> mikekelly: That was an epic thread. I almost got sucked into that on Saturday. Then I regained my senses.
[07:48] <mikekelly> seems like some people are more interested in telling people they don't know what they're talking about
[07:48] <mikekelly> than actually making a coherent point
[07:49] <darrelmiller> fumanchu: I was doing a little reading on your Shoji stuff the other day. Why do you describe it as a protocol as opposed to just a set of related media types?
[07:50] <fu-manchu> that's a good question...I've been rethinking that lately
[07:50] technoweenie (~technowee@host-86-220-9-69.midco.net) joined #rest.
[07:50] <fu-manchu> initially, it was to have a stronger expectation about what you'd get when you followed a link
[07:50] <fu-manchu> but I've been finding good reasons in my own apps to lessen (break) that expectation
[07:50] <darrelmiller> BTW, I like what you are doing. I think this is exactly the level of genericity (is that a word?) that media types need.
[07:51] <fu-manchu> thank you!
[07:51] <fu-manchu> :)
[07:51] <darrelmiller> Can't link relations provide those expectations?
[07:51] <fu-manchu> I think this level of genericity is one of the reasons why Atom got so popular
[07:51] <mikekelly> is that sarcasm ?
[07:51] <mikekelly> ¬_¬
[07:52] <darrelmiller> The problem was that people tried to use Atom outside of the blog world where it was designed.
[07:52] <darrelmiller> and then it became just another envelope format.
[07:52] <mikekelly> well it's all modeled in terms of collections/items
[07:52] <fu-manchu> when they should have been inventing new media types at the same level of genericity which worked for those other domains
[07:52] <mikekelly> which is kind of dumb when we all work in.. resources... :S
[07:53] <darrelmiller> fu-manchu: Exactly.
[07:53] <fu-manchu> unfortunately, I haven't seen many of those other than Shoji :/
[07:53] <darrelmiller> mikekelly: But the contained semantics are specifically related to authoring of articles.
[07:54] <darrelmiller> For the curious... Shoji link http://www.aminus.org/rbre/shoji/shoji-draft-01.txt
[07:54] <fu-manchu> I'm working on a different media type at work right now, for example, and there's a lot of pressure from the business to make it more and more specific
[07:54] <fu-manchu> http://www.aminus.org/rbre/shoji/shoji-draft-02.txt is better :)
[07:54] <darrelmiller> oooh :-)
[07:57] <fu-manchu> I'm even surprised myself at how often I read SO questions now about "how to arrange URI's" and they just scream "I'm a catalog!"
[07:58] <fu-manchu> I originally drafted Shoji when I worked at Etsy, but am using it now for our internal API at YouGov
[07:58] <fu-manchu> Etsy was...rather heavy on the catalog style ;)
[07:58] <darrelmiller> Yeah, I can imagine.
[08:05] <mikekelly> the entity typing there looks very much like the json-ld stuff
[08:07] <mikekelly> I'm not keen on that approach, personally - but that's just my opinion, don't mean to be a dick about it
[08:09] <fu-manchu> I'm not sold on it, personally, either, it just worked a t the time and hasn't had any serious challenges
[08:10] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[08:10] <fu-manchu> I've never had a use case for mixing in dc: or foaf: or what-have-you
[08:10] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Client Quit
[08:11] <mikekelly> it's not that so much as the mechanism itself is actually a generally bad idea from my pov..
[08:12] <mikekelly> in that it encourages clients to 'type' the response based on the entity value in the body - rather than from its 'traversal context' or whwatever you want to call it
[08:12] <mikekelly> so you're basically encouraging clients to hack URIs and 'jump in' to your application at any resource
[08:13] <mikekelly> whereas if the only way they can type the resource is by 'navigating' through the links from an entry point
[08:13] <fu-manchu> I don't follow
[08:13] <darrelmiller> mikekelly: Hey. I'd never thought of that before. By using rel's to provide semantics you force people to do hypermedia. That's interesting.
[08:14] <mikekelly> any form of 'typing' the body to represent something vs. having the type projected onto it by the previous request - allows client devs to "jump into" the app in a way that you don't want them to
[08:14] <darrelmiller> Sneaky.
[08:14] <mikekelly> darrelmiller: it's almost like I designed hal that way
[08:14] <darrelmiller> hahaha!
[08:14] <mikekelly> :D
[08:14] <mikekelly> generic <resource> as the root has same effect
[08:15] <mikekelly> "but I don't know what this is"
[08:15] <mikekelly> "yes you do, because you followed a link, right?"
[08:15] <darrelmiller> Bingo!
[08:15] <mikekelly> "oh... OH. ok cool, I'll just do it that way then"
[08:15] <mikekelly> positive constraints.
[08:15] <fu-manchu> I don't see how that would work in Shoji. The "shoji:catalog" type just declares that its "entities" member contains IRIs--those IRIs could point to radically different resources
[08:16] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 252 seconds
[08:16] <fu-manchu> there's no facility for a client to construct a link
[08:16] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[08:17] <mikekelly> as in the self IRI ?
[08:17] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[08:18] <fu-manchu> {"self": "http://www.my.example/things/";, "element": "shoji:catalog", "entities": ["1/", "2/", "3/"]}
[08:18] <fu-manchu> I don't see where a client dev could "jump into the app"
[08:18] <fu-manchu> because it could just as easily be
[08:19] <fu-manchu> {"self": "http://www.my.example/things/";, "element": "shoji:catalog", "entities": ["1/", "2/", "http:/www.google.com/widgets/fheh/";]}
[08:19] <mikekelly> well the client will be pulling in some semantics based on that typing
[08:20] <mikekelly> I'm just not clear on why you need or would want that kind of typing if you are already guiding all your clients around your app with links anyway
[08:20] <mikekelly> seems kind of redundant
[08:20] <mikekelly> (in my opinion)
[08:22] <fu-manchu> it's a constraint intended to promote cache-friendliness. you can't just drop a link anywhere, it has to be in one of these typed elements, which then govern client expectations about atomicity
[08:22] <mikekelly> cache-friendlyness?
[08:22] <fu-manchu> it's actually much more of a constraint on servers than clients
[08:23] <fu-manchu> Shoji is designed to guide you toward not duplicating data in lots of places, and avoid having copies of entity data therefore get out of sync
[08:23] <fu-manchu> a la Helland's "Apostate's Opinion"
[08:23] <mikekelly> you're fighting HTTP
[08:23] <fu-manchu> no, I'm constraining it to foster certain architectural properties for my apps ;)
[08:24] <mikekelly> that's not a good property if you want a generalised media type
[08:25] <mikekelly> thinking about it - is this much differnet from the '_embedded' property in HAL documents ?
[08:25] <fu-manchu> I don't want to conquer the world with it, I want to foster those properties so the crap my team writes actually scales without me having to write it all myself
[08:25] <fu-manchu> if they follow the spec, that makes my job a lot easier ;)
[08:26] <mikekelly> on a slightly related note, am I the only person who finds JSON-LD 'convoluted' ?
[08:26] <mamund> nope
[08:27] <mikekelly> good, becuase that dude was obviously not happy with that assertion :S
[08:27] <mikekelly> I don't really see why - if you look at the length of the bloody spec it's ridiculous
[08:27] <mikekelly> we're talking about fking JSON :|
[08:28] <mikekelly> funny cos he followed up about 2 posts later and described json-ld's "terse"ness
[08:28] <fu-manchu> perhaps compared to other JSON "solutions"
[08:28] <mamund> rpoly compared to RDF media types
[08:28] <darrelmiller> mikekelly: I just opened the spec, and thought... reallly, this looks way to long for me to bother.
[08:28] <fu-manchu> haha
[08:28] <mikekelly> darrelmiller: I do not think you are alone in that.
[08:29] <darrelmiller> s/to/too Sorry for that.
[08:29] <mikekelly> it's not just tl;dr for me
[08:29] <fu-manchu> if darrelmiller can't be bothered to read through a spec, we are all doomed :)
[08:29] <mikekelly> I just go to the examples they give..
[08:29] <mikekelly> the examples are just ... horrible.
[08:29] darrelmiller Is worried mikekelly will not speak to him if he makes too many grammatical errors
[08:30] <mikekelly> I much more worser than you at grammatical errors
[08:30] <mikekelly> worserer*
[08:30] <mamund> worser-est
[08:30] <fu-manchu> I think you mean "more worst"
[08:30] <mikekelly> mamund: you need to slam me on REST-discuss for bad mouthing your collection+json
[08:30] <mamund> LOL
[08:31] <mamund> naw
[08:31] <mikekelly> oh go on
[08:31] <mamund> it's all shiny
[08:31] <mikekelly> call me a "form-less moron"
[08:31] <mamund> ahhh
[08:31] <darrelmiller> Aren't there enough people bad mouthing you on there already?
[08:31] <mamund> nope
[08:31] <mamund> :)
[08:31] <mikekelly> hahahaha.
[08:31] <mikekelly> +1
[08:31] <mamund> "form-less moron" is pretty damn good, i must say
[08:31] <darrelmiller> mikekelly: You're obviously not trying hard enough.
[08:32] <mikekelly> right - I'm thinking about posting my draft email slamming partial PUT changes to HTTPbis and copying rest-discuss
[08:32] <mamund> now that should help
[08:33] <mikekelly> Roy's diggin his own partial PUT hole
[08:33] <darrelmiller> ROFL
[08:33] <mikekelly> I might just leave him to it so I can laugh at him when it all goes wrong
[08:33] mamund refuses to touch that one
[08:33] <fu-manchu> yeah you'll laugh all the way to the bank
[08:33] <fu-manchu> oh wait...
[08:33] <darrelmiller> mikekelly: Maybe it's safer if you stay in Jersey.
[08:33] <mikekelly> :D
[08:33] <mikekelly> think my email should open with something like
[08:34] <mikekelly> "Roy, the thing you need to understand about HTTP (and REST) is..."
[08:34] <fu-manchu> lol
[08:34] <mamund> yes, yes
[08:34] <darrelmiller> ROFL
[08:34] <mikekelly> :]
[08:34] mamund races to go print up tickets and betting slips
[08:35] <mikekelly> it's tempting just to see if I can induce Eric Bowman into a coranary just with the power of words
[08:35] <darrelmiller> It's a good job I don't have a cracked rib anymore, or I would be in a whole lot pain,
[08:35] <mikekelly> I'm not sure I can spare the time, and he's clearly pretty set on the change and not really interested in discussing it
[08:36] <mikekelly> (I'm a wimp)
[08:39] <mikekelly> it is fking stupid though.
[08:39] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) left irc: Quit: Leaving.
[08:39] darrelmiller not biting
[08:39] <mikekelly> :)
[08:41] Jarda (~jarda@narhinen.net) joined #rest.
[08:49] technoweenie (~technowee@host-86-220-9-69.midco.net) left #rest ("Leaving...").
[08:57] aGHz (~Adium@modemcable048.88-80-70.mc.videotron.ca) joined #rest.
[08:58] <mikekelly> emulated CURIEs with URI templates and Web Linking link properties
[08:58] <mikekelly> omgpwnedlol
[08:58] DracoBlue (~Adium@p5B3D4AD5.dip.t-dialin.net) joined #rest.
[08:59] <darrelmiller> Web Linking link properties? link?
[08:59] <mikekelly> I just meant "title" from the Web Linking draft
[09:00] <mikekelly> I haven't actually re-written it yet but I'm going to add all the bits from Web Linking in there
[09:00] <mikekelly> like title and hreflang or whatever it is
[09:00] <darrelmiller> Cool.
[09:01] <mikekelly> but, basically my point was you can emulate CURIEs with a URI template like this:
[09:01] <mikekelly> "_links" : {
[09:01] <mikekelly> "curie": { "href": "http://example.com/rels/{relation}", "title": "ex" }
[09:01] <mikekelly> },
[09:01] bigbluehat (~bigblueha@adsl-74-177-98-159.gsp.bellsouth.net) left irc: Quit: Leaving.
[09:02] <mikekelly> without having to bloat HAL with a CURIE mechanism most people don't want
[09:03] <mikekelly> maybe people do want it, but most of the feedback I got about the CURIE stuff in the old example I had was "wtf is this doing in the property names?!?!"
[09:03] <darrelmiller> I 'm using URNs now. rel="urn:tavis:foo" I realize you can't dereference to get docs, but I don't care.
[09:03] DracoBlue (~Adium@p5B3D4AD5.dip.t-dialin.net) left #rest.
[09:03] <mikekelly> can't urns have tranlation rules to other schemes ?
[09:04] <darrelmiller> dunno.
[09:04] <mikekelly> or is that A Bad Idea ?
[09:04] <mikekelly> either way that's cool and I think it's a good way to go
[09:05] <darrelmiller> No I don't think it is a bad idea.
[09:06] <darrelmiller> I just have got used to have to search for media type specs, and I don't have a problem doing the same for link relation specs.
[09:09] <mikekelly> hm, I would kind of dig some kind of mechanism for that
[09:09] <mikekelly> e.g. where I'm at at the moment I'm currently revamping the API and writing the 'documentation' for clients
[09:09] <mikekelly> and a big part of that will be a 'browser' for the API
[09:10] <mikekelly> having 'clickable' rels that pop up a documentation page is important
[09:10] <mikekelly> because it makes the docs discoverable
[09:10] <mikekelly> just as the app
[09:13] caaakeeey (~cakery@gatekeeper-ext.zeus.com) joined #rest.
[09:13] <mikekelly> or.. maybe that's a dumb idea?
[09:13] <caaakeeey> best way to make an api fully explorable in the browser?
[09:13] <darrelmiller> Gotta kick that's browser habit Mike, it'll kill you eventually.
[09:13] <mikekelly> caaakeeey: yeah, that's the theory
[09:14] <caaakeeey> mikekelly, yes but how do i go about doing this, ie turning urls in json into actual hyperlinks... is there some kind of jscript module?
[09:15] <mikekelly> yeah I'm writing a generic single page javascript app that can 'surf' on APIs exposed using application/hal+json
[09:15] <darrelmiller> I can give you my XSLT that transforms HAL into XHTML if you like :-)
[09:16] <mikekelly> or that^
[09:16] <mikekelly> :)
[09:16] <darrelmiller> oh right, that would need to be XML based hal :-)
[09:16] <darrelmiller> Forgot JSON doesn't have transforms ... hehe
[09:16] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) left irc: Quit: Leaving...
[09:17] <mikekelly> caaakeeey: but this doesn't exist publicly yet I need to get it done and then clear it with the people who I'm working for
[09:17] <mikekelly> it'll go up on github when it's done hopefully
[09:17] <caaakeeey> surely someones already done it?
[09:17] <mikekelly> well hal hasn't been around for that long
[09:17] ssedano (~ssedano@unaffiliated/ssedano) left irc: Quit: WeeChat 0.3.4
[09:17] <mikekelly> I dunno if this exists for atom or something like that
[09:18] <mikekelly> as darrelmiller said, it does already exist as XSLT for the XML version of HAL
[09:20] <mikekelly> caaakeeey: or were you thinking of something else ?
[09:20] <mikekelly> caaakeeey: much of the problem is that most people go off and produce their own custom media types for everything
[09:20] <mikekelly> so we don't see a lot of this
[09:20] <mikekelly> hopefully if/when people start using HAL more we will see more of this kind of stuff for APIs
[09:23] <fu-manchu> caaakeeey: they exist
[09:24] <fu-manchu> Chrome: "https://chrome.google.com/extensions/detail/chklaanhfefbnpoihckbnefhakgolnmc";,
[09:24] <fu-manchu> IE: "http://stackoverflow.com/questions/2483771/";,
[09:24] <fu-manchu> Firefox: "https://addons.mozilla.org/en-us/firefox/addon/jsonview/";
[09:24] <fu-manchu> (I include links to those in the root URI of all my JSON-based apps now)
[09:25] <fu-manchu> links have to have a scheme part (like "http://";) to be recognized
[09:39] ssedano (~ssedano@unaffiliated/ssedano) joined #rest.
[09:39] dkubb (~dkubb@50.92.131.237) left irc: Quit: Linkinus - http://linkinus.com
[09:41] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[09:42] bigbluehat (~bigblueha@adsl-74-177-98-159.gsp.bellsouth.net) joined #rest.
[09:44] mr_yall (~mr_yall@scifo.mexico86.co.uk) left #rest ("Killed buffer").
[09:59] DracoBlue (~Adium@p5B3D4AD5.dip.t-dialin.net) joined #rest.
[09:59] DracoBlue (~Adium@p5B3D4AD5.dip.t-dialin.net) left irc: Client Quit
[10:37] caaakeeey (~cakery@gatekeeper-ext.zeus.com) left irc: Ping timeout: 252 seconds
[11:08] DracoBlue (~Adium@p5B3D4AD5.dip.t-dialin.net) joined #rest.
[11:08] DracoBlue (~Adium@p5B3D4AD5.dip.t-dialin.net) left #rest.
[11:09] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Remote host closed the connection
[11:09] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[11:19] aGHz (~Adium@modemcable048.88-80-70.mc.videotron.ca) left irc: Quit: Leaving.
[11:46] 64MAAG5H1 (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) joined #rest.
[12:03] mephju (~mephju@dslb-188-102-111-180.pools.arcor-ip.net) left irc: Quit: Ex-Chat
[12:14] aGHz (~Adium@74.198.165.75) joined #rest.
[12:54] NOKAH (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[12:58] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Ping timeout: 268 seconds
[13:24] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Quit: Wombert
[13:28] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) joined #rest.
[13:38] aGHz (~Adium@74.198.165.75) left irc: Quit: Leaving.
[13:48] <64MAAG5H1> The "implementing-rest" wiki has an extensive list of REST frameworks. I've just completed a prototype using CXF with Jackson...any reason it didn't make the list?
[13:48] <mamund> 64MAAG5H1: hi
[13:48] <mamund> most likely because no one volunteered to add it to the list<g>
[13:48] <64MAAG5H1> np
[13:48] <mamund> would you like to do it?
[13:48] <64MAAG5H1> sure
[13:48] <mamund> cool
[13:50] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest.
[13:52] <darrelmiller> It can be dangerous asking questions here. Who knows what you can get volunteered for...
[13:52] aGHz (~Adium@74.198.165.75) joined #rest.
[13:52] <mamund> :)
[13:52] <mamund> took 64MAAG5H1's details off line, he'll be up and running soon
[13:53] <64MAAG5H1> lol
[13:53] <64MAAG5H1> I found the site helpful and am more than happy to add my 2 cents...
[13:54] mamund rubs hands togther, smirks, and mumbles something about 'fresh meat'
[13:54] <darrelmiller> That's how we suck you in.
[13:54] <mamund> :)
[13:54] <mamund> 64MAAG5H1: srsly, glad it was helpful
[13:54] darrelmiller first hit is free.
[13:54] <mamund> thanks for adding to the wiki, too.
[13:54] <64MAAG5H1> np -- my nick is hdave ... not seeing 64MAAGSH1
[13:54] <mamund> ha
[13:55] <64MAAG5H1> mamund: my pidgin install must have a screw loose....
[13:55] <mamund> heee
[13:55] <mamund> likely
[13:55] <darrelmiller> Hey hdave. I like your most recent question on SO. I upvoted it.
[13:55] <64MAAG5H1> wait until I start pummeling everyone with stupid newbie HATEOAS questions....
[13:55] <mamund> this is the place!
[13:55] <mamund> just e sure to wear your fireproof shorts, tho<g>
[13:56] <64MAAG5H1> darrelmiller: thanks. I read every post on SO you've made on REST....must be about 20+ answers/comments....very good stuff
[13:56] <64MAAG5H1> upvoted you 10 times...lol
[13:57] <64MAAG5H1> you can send me a check later ;-)
[13:57] <darrelmiller> Keep searching... I currently have 628 answers in the REST tag :-)
[13:57] mamund _new_ darrelmiller had a scam going over at SO
[13:58] <64MAAG5H1> nice...
[14:02] <darrelmiller> HDave: Regarding your last question, according to the wikipedia definition, RIAs live in the browser and therefore they are downloaded by the browser. REST allows clients and servers to evolve independently therefore, RIAs don't really benefit much from REST.
[14:02] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left irc: Quit: Leaving.
[14:02] <darrelmiller> They can benefit from HTTP's layered architecture though. Issues like caching and statelessness are still very relevant.
[14:03] fu-manchu has given up trying to catch up to darrelmiller on SO
[14:04] <darrelmiller> fu-manchu: Hey, you're still ahead of me for the month.
[14:04] <fu-manchu> but I will point out caching and statelessness are constraints of REST, not just HTTP add-ons ;)
[14:05] <64MAAG5H1> darrelmiller: it makes sense to me that RIA and REST are not very complementary....but yet I can see benefits of REST.
[14:05] <darrelmiller> fu-manchu: I sit corrected.
[14:06] <64MAAG5H1> darrelmiller: in fact, I have a totally crazy idea that I was too shy to include on SO, but perhaps here
[14:06] <mamund> darrelmiller: if the "RIA" was executable outside the web browser, does that change anything (REST-wise)?
[14:06] bigbluehat (~bigblueha@adsl-74-177-98-159.gsp.bellsouth.net) left irc: Quit: Leaving.
[14:06] <darrelmiller> DaveH: Yes some of REST's constraints are still applicable and very beneficial.
[14:07] <64MAAG5H1> mamund: I hope darrelmiller says it wouldn't change anything....the only reason our app runs in a web browser via Javascript is to gain platform independence. If fact we are using Flex and GWT for HTTP communication.
[14:09] <64MAAG5H1> darrelmiller: my crazy idea is that we could make a (nearly) totally generic GWT app for REST resource CRUD operations and we'd have 80% of our app done forever.
[14:09] <64MAAG5H1> just add CSS...
[14:10] <darrelmiller> Ok. hold up. If your GWT app makes HTTP requests to a different server for the REST represenations then you may have a valid case.
[14:11] <darrelmiller> So you want your GWT to evolve independantly to the services right?
[14:11] <64MAAG5H1> darrelmiller: we are not trying to get around SOP or anything. We just have GWT code that invokes the HTTP REST Api to gain access to entities
[14:11] <64MAAG5H1> darrelmiller: yes -- the idea is that the GWT app can be more simple...more generic....with less apriori knowledge of the services and all the entity types
[14:11] <darrelmiller> Ok, so then I take back what I said.
[14:12] <darrelmiller> So what you are really trying to do is write a web browser than runs within a web browser ;-)
[14:13] <64MAAG5H1> yes
[14:13] <mamund> eseentially xmlhttp, right?
[14:13] <64MAAG5H1> no idea what xmlhttp is sorry...
[14:13] <mamund> s/xmlhttp/xmlhttprequest
[14:13] <64MAAG5H1> ah
[14:13] <64MAAG5H1> yes
[14:14] <mamund> in web browsers, you're limited in how much of the protocol you can see/modify, but most of it is there.
[14:15] <64MAAG5H1> I think darrelmiller -- hit on the source of my confusion....if you are writing a RIA that takes full advantage of HATEOAS then you are writing your own specialized web browser...that runs in a web browser.
[14:16] <darrelmiller> My opinion is that what you are trying to do is going to be quite difficult to do restfully.
[14:16] <darrelmiller> The reason is that you need to manage a state machine that runs within another statemachine.
[14:17] <darrelmiller> The web browser is the outer statemachine and your GWT app is your inner state machine.
[14:17] <darrelmiller> You are ok as long as your GWT state machine is just a set of states within a single web browser state.
[14:17] <64MAAG5H1> but we are using the outer state machine for (almost) nothing...
[14:17] <64MAAG5H1> i think it is
[14:17] <darrelmiller> The problem comes when you transition from one web browser state to another and you need to maintain some of the GWT app state.
[14:18] <64MAAG5H1> like the back button?
[14:18] <darrelmiller> Or any <a> link in your HTML.
[14:19] <64MAAG5H1> I don't have any HTML...I just have GWT code (Javascript) making HTTPRequests and manipulating the DOM...there are no clickable links per se in the app
[14:19] <64MAAG5H1> just buttons, menus, grids, etc.
[14:19] <darrelmiller> or right click, open in new window.
[14:20] <darrelmiller> if everything is managed by JS then you are ok, but sooner or later the browser frame starts to become a liability.
[14:21] <64MAAG5H1> Yes...For that reason we were thinking of moving to Air, but Adobe dropped Air support from Linux and ticked me off, then they dropped Flash on mobile devices and (IMO) shot themselves in the foot....so we are back to the browser for better or worse
[14:21] <64MAAG5H1> Our Flex/Flash client died before it was born...
[14:23] <64MAAG5H1> to beat a dead horse...with GWT, we're planning on using an MVP framework...we have no MVC on the server
[14:23] <darrelmiller> My current theory is that in the long term, having a very thin native app is going to be easier.
[14:23] <darrelmiller> ..on each platform you support.
[14:23] mamund darrelmiller has been down the road before
[14:24] <64MAAG5H1> hmmmm
[14:24] <darrelmiller> I'm talking "stategically" long term. 5 -10 years.
[14:25] <darrelmiller> s/stategically/strategically
[14:25] <64MAAG5H1> right.....will have to think about that. I've been so focused on web technology for so long, it hadn't even occurred to me.
[14:26] <64MAAG5H1> so in the end, my SO question might just as well been about rich client desktop applications and REST/HATEOAS
[14:26] <64MAAG5H1> s/been/have been
[14:28] <darrelmiller> My favourite phrase at the moment is "The web browser is just another app" :-)
[14:29] <mamund> darrelmiller: how long have you been working implementing hypermedia clients (outside the browser)?
[14:30] <darrelmiller> I started down this path in 2006.
[14:30] <mamund> wow, earlier than i thought
[14:30] <mamund> (figured 2008, for some reason)
[14:30] <mamund> that's very cool, tho.
[14:30] <64MAAG5H1> darrelmiller: it is just another app, but its an app that can be found on every desktop and can (almost) always be expected to run Javascript
[14:31] <64MAAG5H1> mamund: I have been a developer/architect for 17 years and I have to say this REST stuff really caught me off guard. It's deceptively simple. Its been a long time since I can recall having my mind blown like this...
[14:32] <mamund> hDave: "desceptively simple" is a good way to put it, IMO.
[14:32] mamund wishes he could spel, tho.
[14:32] <darrelmiller> +10 and +10 for "mind blowing"
[14:33] <mamund> i spent the last 2+ years working on the hypermedia constraint (ok, i'm a bit of a freak)
[14:34] <mamund> and am just _starting_ to get around to visibility, self-descriptive, and stateless
[14:34] <64MAAG5H1> Its the hypermedia constraint that is the critical ingredient for me....otherwise you have HTTP based RPC
[14:34] <mamund> yep, that's what i think
[14:35] <mamund> and why i persevered on it for quite a while<g>.
[14:35] <64MAAG5H1> which I am not knocking, by the way....I actually think HTTP-RPC is WAY better than SOAP...at least for our purposes
[14:35] <mamund> IMO, it's the primary thing that sets Fielding apart from others in this space.
[14:35] <64MAAG5H1> right
[14:35] <darrelmiller> Another of my favourite phrases "It is the hypermedia constraint that makes REST as a style greater than the sum of its constraints. It is the focal point and amplifier of all the constraints. – Aristotle Pagaltzis"
[14:36] <64MAAG5H1> With a name like "Aristotle Pagaltzis" , you deserve to be quoted ;-)
[14:37] <mamund> my last round of reading on affordances (both UI design and psychology of visual percpection/cognition) ...
[14:37] <mamund> also informed me a great deal about why hypermedia style has such an impact on the implementaiton details.
[14:38] sbanwart (~sbanwart@72.240.63.122) joined #rest.
[14:38] <mamund> really amazing that this aspect of Fielding has gone so long unexplored, IMO.
[14:39] <64MAAG5H1> for sure - but it is also difficult to grasp
[14:39] mamund so.... that was too much, right<g>?
[14:39] <mamund> :)
[14:40] <darrelmiller> mamund: made me feel all warm and fuzzy
[14:40] <mamund> heee
[14:40] <darrelmiller> and hungry.
[14:40] <darrelmiller> Time to go eat. Later folks.
[14:40] <64MAAG5H1> for example -- in comment #31 in his blog (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven) he states this "One of the easiest ways to see that is when a protocol calls for the use of a generic media type (like application/xml or application/json) and then requires that it be processed in a way that is special to the protocol/API. If they are keying off of something unique within the content (like an XML n
[14:40] <mamund> toodles
[14:41] <64MAAG5H1> darrelmiller: thanks for the help....later
[14:41] <mamund> hDave: that is a a great blog post
[14:41] <64MAAG5H1> it is....very helpful clarification
[14:42] <mamund> one of the things that spurred me to finally try to codify hypermedia in a way i could share w/ others
[14:42] <64MAAG5H1> but his comment blows my mind....how is a Javascript based web-app going to be able to render my business entities in the right way if it doesn't have prior knowledge of what they are?
[14:42] <64MAAG5H1> unless my server just sends out HTML
[14:42] <mamund> :)
[14:43] <mamund> so many things in the Q....
[14:43] <mamund> "able to render"
[14:43] <mamund> "right way"
[14:43] <mamund> "prior knowledge"
[14:43] <mamund> or "just send HTML"
[14:43] <mamund> <g>
[14:43] <64MAAG5H1> lol
[14:44] <mamund> HTML doesn't have _any_ of those other things, right?>
[14:44] <darrelmiller> HDave: Here's clue. Use something like HAL and data driven data binding.
[14:44] <64MAAG5H1> will look that up...
[14:45] <64MAAG5H1> mamund: perhaps a simpler question. Would you consider using XMLHttpRequest to be (essentially) a violation of HATEAOS?
[14:45] <mamund> absolutely not.
[14:45] <mamund> hypermedia design is not bound to any particular implemetation detail
[14:46] <mamund> does that make sense?
[14:46] <mamund> (or make it 'worse'<g>)
[14:46] <64MAAG5H1> yes -- agree, but...
[14:47] <64MAAG5H1> practically speaking 99% of the time XmlHttpRequest returns a serialized object with media type application/xml that only javascript code can do something meaningful with, yes?
[14:48] <mamund> LOL, that's not the 'fault' of XMlHTtpRequest, right?
[14:48] <mamund> so the Q is:
[14:48] <fu-manchu> indeed, mobile code is part of the REST constraints
[14:48] <mamund> "is sharing serialized private objects, void of hypermedia, a violation of REST?
[14:48] <mamund> and my answer would be "yes"<g>
[14:48] <64MAAG5H1> mamund: perfect...got it
[14:49] <mamund> as i work more and more on designing w/ hypermedia as a prime component
[14:49] <mamund> i notice that i spend more time "programming the message"
[14:49] <64MAAG5H1> fu-manchu: do you mean that mobile code is acceptable or not-acceptable?
[14:50] <fu-manchu> acceptable
[14:50] <mamund> and wishing that the "client" would just _understand_ the message 'automatically'<g>
[14:50] <fu-manchu> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7
[14:51] <fu-manchu> it's an "optional constraint"
[14:52] <64MAAG5H1> fu-manchu: thats help...I've read the doc before, but somehow missed equating code on demand with my Javascript
[14:52] <64MAAG5H1> s/help/helpful
[14:52] <mamund> hdave: i've written complete hypermedia parsers in JS before (and run them in a browser)
[14:53] <mamund> i've also shipped custom Hypermedia XML around and, for browsers, included an XSLT reference that
[14:53] <mamund> would allow browsers to render HTML and link to CSS/JS when the recieve the XML.
[14:53] <mamund> that's really a hypermedia parser, too.
[14:55] <mamund> i claim you can do those things w/o adversely affecting visibility and self-description, too.
[14:55] <64MAAG5H1> mamund: I've been thinking about the XSLT approach as well. This way, the server is not burdened with HTML creation (which frankly I don't believe is its job) and yet we can get to our DOM/HTML without writing a ton of Javascript...
[14:56] <mamund> that's def a possibility
[14:56] <mamund> i started doing the XSLT against custom XML years ago when...
[14:56] <mamund> i was deep in a custom XML project and needed a quick way to "prototype" UI and test functionality...
[14:57] <mamund> w/o coding up a desktop app (which was the target for the customer)
[14:57] <64MAAG5H1> mamund: in the end, my web-app is really just there to perform CRUD operations on various business entities...its really nothing special except that there are a ton of these entities and they are in complex graphs, and the version controlled schema that defines them is under the control of the user
[14:57] <mamund> i still use it; even for some "production apps"
[14:57] <mamund> well, not sure of your situation, but...
[14:58] <64MAAG5H1> so I really just need a fancy editor that can "edit" any kind of "entity"....
[14:58] <mamund> if CRUD is your space, you don't need too much hypermedia, right?
[14:58] <mamund> atom gets to CRUD w/ rel="edit" and a single 'root' element
[14:59] <mamund> (they skip forms, ad-hoc queries, and transclusion vs/ navigation)
[14:59] <mamund> so, it shouldn't be too tough
[14:59] <64MAAG5H1> but there are rules about when you can create and when you can't, which entities can live under which entities, which ones have a new revision made, what their status is, when their effectivity is, etc. so many operations with many constraints....
[14:59] <mamund> to design a hypermedia format _and_ implement a client that can....
[14:59] <64MAAG5H1> so instead of hard-coding this into my javascript, I could provide all these details with the "resource" to be edited
[15:00] <mamund> recognize, parse, render, and (when needed) activate the CRUD controls)
[15:00] <mamund> yep
[15:00] <mamund> using XML or JSON as the base format?
[15:01] <64MAAG5H1> I support both for now
[15:01] <mamund> <create /> or <action type="create" />
[15:01] <64MAAG5H1> but i am leaning towards JSON
[15:01] <mamund> {"create" :[...]} or {"action": {"type":"create",[...]}}
[15:02] <mamund> or some variation
[15:02] <64MAAG5H1> right....
[15:02] <mamund> check out HAL, AtomPub, Collection+JSON
[15:02] <mamund> they are all lightweight hypermedia designs
[15:02] <mamund> you can use them, or if you really need to, roll your own
[15:03] <64MAAG5H1> is this the HAL you refer too? http://stateless.co/hal_specification.html
[15:03] <mamund> yep
[15:04] <mamund> very lightweigth, based on "rel" as the only key 'decorator' of the message
[15:04] <64MAAG5H1> HAL is looking like its exactly what I need (after 7 seconds of reading)
[15:04] <mamund> darrelmiller: has experience w. it
[15:04] <mamund> mikekelly hangs here (he's the one who created HAL)
[15:07] <64MAAG5H1> mamund: thanks for the help...i have lots to digest!
[15:07] <mamund> :)
[15:07] <mamund> that's what we're here for
[15:08] mamund must new _really_ close out that feature request!
[15:13] NOKAH (~hakon1@193.137.202.84.customer.cdi.no) left irc: Remote host closed the connection
[15:13] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[15:21] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Computer has gone to sleep.
[15:30] mamund can relax now as the feature was rolled out w/o a whimper from the servers and the phone remain silent sentinels to my awesome skilz.
[15:41] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Read error: Connection reset by peer
[15:41] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[15:48] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[15:52] mamund is staisfied; heading out. fin!
[16:01] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) left irc: Remote host closed the connection
[16:01] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) joined #rest.
[16:06] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) left irc: Ping timeout: 268 seconds
[17:23] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Computer has gone to sleep.
[17:26] talios (~textual@akl.smx.co.nz) joined #rest.
[17:27] <talios> hey darrelmiller :)
[17:27] talios puts on his dancing shoes and says "let the rel fight begin" :) heh
[17:47] <darrelmiller> talios: haha!
[17:47] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[17:50] <darrelmiller> talios: I believe there is a continuum in REST where at one end you have a link relation that defines lots of semantics that point to a generic media type and at the other end the link relation specifies very little semantics and the media type is very specific.
[17:50] <darrelmiller> HAL falls at one end of the spectrum.
[17:51] <darrelmiller> link relations like next and previous fall at the other.
[17:52] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) joined #rest.
[17:54] <talios> hey :)
[17:54] <talios> Just writing a followup email - which might actually satisfy my issue somewhat.
[17:55] <darrelmiller> ok cool.
[17:55] <talios> -might- :)
[18:00] <talios> and posted :)
[18:02] <talios> mike's email mentioned "rels", which I think it the first time I've seen the plural reference being mentioned, so I could use rel="manager lite"
[18:03] <darrelmiller> Yes, that's part of the web linking spec and Mike has explicitly said that we should support that in Hal.
[18:03] <talios> Excellent - I shall bring out my toys and play again then :)
[18:04] <darrelmiller> Personally, I would implement it client side as a LiteManager and FullManager rel that derive from the the ManagerRel, but that's just an implementation detail.
[18:09] <talios> I've currently taking a slightly different approach in my HalBuilder java library, using a structural type style API - https://gist.github.com/ab225838ca5c6e39039
[18:09] <talios> altho thats more for the processing of the content once you've decided what it should contain
[18:10] <darrelmiller> I'm getting a 404 on that link
[18:10] <talios> https://gist.github.com/ab225838ca5c6e39039d - cut and pasted one less char
[18:10] <talios> :(
[18:11] <talios> I also have isSatisfiedBy(Class) and renderClass(Class) methods ( that returns a proxy implementing the class )
[18:12] <talios> ( https://github.com/talios/halbuilder/blob/develop/src/test/java/com/theoryinpractise/halbuilder/InterfaceSatisfactionTest.java )
[18:16] <darrelmiller> Yeah, ok. I think I can grok that.
[18:17] <talios> Starting to write myself a real-world sample app to flesh out what's broken/improvable in the usage side of things. Looking good so far for the most part.
[18:17] <darrelmiller> It looks like a very flexible way of mapping strongly typed entities into the loosy goosy world of hal.
[18:18] <talios> that was the intention.
[18:18] aGHz (~Adium@74.198.165.75) left irc: Quit: Leaving.
[18:27] sbanwart (~sbanwart@72.240.63.122) left irc: Ping timeout: 240 seconds
[18:52] <talios> darrelmiller - did you see my recent HATEOAS blog posts at all? ( I've seen no hate mail so maybe not ) ;p http://theoryinpractise.tumblr.com/post/14843929966/practical-hateoas-pimping-geekzone-part-1
[18:53] <darrelmiller> No I haven't. I'll take a look.
[18:54] <talios> theres also currently one followup post, I have others planned.
[19:10] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) joined #rest.
[20:41] talios (~textual@akl.smx.co.nz) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[22:11] dkubb (~dkubb@50.92.131.237) joined #rest.
[22:41] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[23:12] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Quit: quest88
[23:23] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Computer has gone to sleep.
[23:24] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[23:30] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) joined #rest.
[00:00] --- Tue Jan 10 2012