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

[00:05] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) joined #rest.
[00:37] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) joined #rest.
[00:51] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) left irc: Quit: brb
[01:05] talios (~textual@ip-118-90-11-129.xdsl.xnet.co.nz) joined #rest.
[01:57] mikekelly -> mk_
[02:22] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) left irc: Ping timeout: 240 seconds
[02:24] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) joined #rest.
[02:28] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) left irc: Ping timeout: 252 seconds
[02:45] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest.
[02:46] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left #rest.
[03:20] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[03:27] talios (~textual@ip-118-90-11-129.xdsl.xnet.co.nz) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[03:40] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) joined #rest.
[03:43] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) got netsplit.
[03:47] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) returned to #rest.
[04:32] zazi (~zazi@p5DDA99C3.dip.t-dialin.net) joined #rest.
[04:32] <zazi> are there public logs of this channel available somewhere?
[04:40] <zazi> or could someone provide me a log snipped of the discussion I was involved yesterday?
[04:41] <zazi> (mailto: zazi@smiy.org) thx a lot in advance
[04:41] zazi (~zazi@p5DDA99C3.dip.t-dialin.net) left irc: Quit: HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC
[04:47] zazi (~zazi@p5DDA99C3.dip.t-dialin.net) joined #rest.
[05:13] <darrelmiller> zazi: Logs are here http://rest.hackyhack.net
[05:14] <Jarda> f**king async tasks
[05:14] <darrelmiller> :-)
[05:14] <darrelmiller> They're great when they work.
[05:14] <Jarda> trying to spin my head around..
[05:15] <Jarda> xaml databinding and async tasks
[05:15] <Jarda> no fucking clue why my UI hangs
[05:15] <Jarda> and hard to debufg
[05:15] <Jarda> I have to have some while() {} or task.Wait(); somewhere
[05:16] <Jarda> task.ContinueWith(v => dispatcher.BeginInvoke(new Action(() => callback(v.Result)))); shouldn't really hang, I guess..
[05:16] 64MAAG5H1 (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) left #rest.
[05:17] <darrelmiller> Have you read this article on deadlocking ? http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115163.aspx
[05:18] <Jarda> oh fuck
[05:18] <Jarda> fetching v.Result hangs?
[05:18] <Jarda> or not
[05:19] <darrelmiller> It can if you use it on the calling thread and there is some other callback that uses the calling thread.
[05:19] hdave1 (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) joined #rest.
[05:19] <darrelmiller> Doing v.Result in a ContinueWith should not be an issue.
[05:19] <Jarda> oh, true
[05:19] <Jarda> but I guess I know where my problem is
[05:20] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) left irc: Quit: Computer has gone to sleep.
[05:20] <Jarda> not there at all
[05:20] <Jarda> I'm actually doing sync stuff..
[05:29] <zazi> thx, darrelmiller (I must be blind :\ )
[05:30] <darrelmiller> zazi: No problem! You can thank KevBurnsJr for our logs.
[05:30] <Jarda> bah
[05:30] <Jarda> I'm transforming some JSON stuff to objects
[05:31] <Jarda> and I have a custom converter that reads hypermedia and fetches the representation and makes it an object
[05:31] <Jarda> and it has to return it, so it's sync
[05:31] <Jarda> blah
[05:32] <Jarda> have to change to some custom lazy load situation
[05:33] <darrelmiller> Can you not run that stuff on a bacground worker thread?
[05:34] <darrelmiller> RESTAgent does that automatically now :-)
[05:34] <Jarda> yeah well I don't know
[05:34] <Jarda> this all gets a bit messy because me and threads don't work well..
[05:34] <darrelmiller> I hear you.
[05:35] <Jarda> but using async tasks doesn't help, if you call Wait() on them, right? :)
[05:35] <Jarda> if the ui needs the return, then it needs it..
[05:35] <Jarda> of course {Binding Async=True..}
[05:37] <darrelmiller> yes of course. If you async load then you can show any data on the UI until the request finishes.
[05:38] <darrelmiller> However, I find UI's tend to take a while to build up and render. Loading and parsing the data while that is happening seems to be an effciient course of action.
[05:38] <darrelmiller> s/can/cannot
[05:51] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) joined #rest.
[06:05] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) joined #rest.
[06:13] mattis (~mattis@62.73.197.123) left #rest.
[06:23] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest.
[06:28] saml (~sam@adfb12c6.cst.lightpath.net) joined #rest.
[06:28] <saml> hey
[06:28] <saml> how do you send multiple binary files and names of the files ?
[06:28] <saml> multipart/form-data ?
[06:32] <darrelmiller> You could. Or you could just zip them and send them with some kind of manifest file.
[06:33] <saml> how about json?
[06:33] <darrelmiller> I think there is actually a standard for that. I can't remember the name though.
[06:33] <saml> json with base64 encoding of binary?
[06:34] <darrelmiller> Yeah you could but that seems like a pretty painful and inefficient format.
[06:34] <saml> standard?
[06:36] peterwilliams (~Adium@webmail.openlogic.com) joined #rest.
[06:37] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) left irc: Quit: Computer has gone to sleep.
[06:38] <darrelmiller> hey! peterwilliams Good to see you here.
[06:40] <darrelmiller> saml: I can't find the packaging format I was thinking of. I'll ping you here if it comes to mind.
[06:41] <saml> thanks darrelmiller
[06:42] <darrelmiller> saml: here it is http://msdn.microsoft.com/en-us/magazine/cc163372.aspx It's a MS thing, so I don't know how widely used it is outside the the MS world.
[06:46] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest.
[06:46] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left #rest.
[06:49] <peterwilliams> darrelmiller, thanks
[06:58] <hdave1> mamund: don't forget to send me the email so I can the CXF stuff to the wiki
[07:01] pezra (~Adium@webmail.openlogic.com) joined #rest.
[07:02] peterwilliams (~Adium@webmail.openlogic.com) left #rest.
[07:02] <zazi> outch, Web Intents implement already my thinkings from yesterday (more or less) // to bad that I didn't informed myself what Web Intents really are earlier :)
[07:03] <darrelmiller> zazi: Look on the bright side, you didn't spend a month working on something before finding it :-)
[07:03] <zazi> hehe
[07:04] <zazi> although thier idea came from another background
[07:05] <zazi> "Web Intents is a framework for client-side service discovery and inter-application communication"
[07:08] <mk_> of course
[07:08] <mk_> their example looks like
[07:08] <mk_> a link
[07:08] pezra (~Adium@webmail.openlogic.com) left irc: Quit: Leaving.
[07:08] <mk_> and a link rel
[07:09] darrelmiller is MikeKelly wearing a disguise today?
[07:09] pezra (~pezra@webmail.openlogic.com) joined #rest.
[07:09] <mk_> yeah
[07:09] <mk_> since people seem to be posting links to the logs more
[07:09] <zazi> the tipping point they utilise an 'action' attribute with a URI as value
[07:09] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) left irc: Quit: brb
[07:09] <darrelmiller> mk_: Sneaky move.
[07:09] <mk_> I should probably make a tit of myself here semi-anonymously
[07:10] <zazi> :)
[07:10] <mk_> can't believe there's > 40 people in here
[07:10] <mk_> awesome :)
[07:10] <darrelmiller> mk_: I'm sure for a few beers Kev will do some editing for you.
[07:10] <mk_> haha
[07:11] <mk_> secret overlord conspiracy theories abound
[07:11] <darrelmiller> s/mikekelly/mamund :-)
[07:11] <mk_> right
[07:11] <mk_> s/mamund/mikekelly_ then s/mikekelly/mamund
[07:11] <mk_> ohw ait
[07:11] <mk_> lol
[07:11] <mk_> :)
[07:11] <mk_> I suck
[07:12] <mk_> %s/mamund/tmptmptmp/g , %s/mikekelly/mamund/g , %s/tmptmptmp/mikekelly/g
[07:12] <darrelmiller> mk_: Well, I hear people do talk to themselves a lot when they get older.
[07:12] <mk_> ha.
[07:13] <mk_> he's going to snap eventually and perma-ban you
[07:13] <darrelmiller> I was just thinking I may not get invited back to RESTfest if I'm not careful.
[07:13] <mk_> or you will and you will "go missing"
[07:15] <bigbluehat> darrelmiller: what are you up to now :)
[07:16] <darrelmiller> Oh... I may have made a couple of passing remarks about mamumd's "seniority" ;-)
[07:17] <mk_> bigbluehat: congrats on that talk btw
[07:17] <mk_> cool stuff
[07:17] <darrelmiller> bigbluehat: Yeah, very nice.
[07:17] <mk_> very well delivered too
[07:18] <mk_> your crazy-scientists hair to has got even crazier since I saw you
[07:18] <mk_> good effort
[07:18] <mk_> ahir do^
[07:18] <mk_> hair do ^^^^
[07:19] mamund re-appears
[07:20] pezra (~pezra@webmail.openlogic.com) left irc: Quit: Leaving.
[07:20] pezra (~Adium@webmail.openlogic.com) joined #rest.
[07:21] <darrelmiller> mamund: Hey, how are you doing. You are looking mighty fine today.
[07:21] <mk_> don't be patronising.
[07:21] <darrelmiller> wha! me?
[07:22] <zazi> Web Intents actions are site specific, i.e. one action/intent per web site?
[07:22] <mk_> no I don't think so I think they're supposed to be re-0used
[07:22] <zazi> no that's not what I meant here
[07:23] <mk_> oh you meant granularity ?
[07:23] <zazi> e.g. http://www.cloudfilepicker.com/ has one 'intent' definition
[07:23] <zazi> e.g. http://www.imagemator.com/ has one 'intent' definition (view)
[07:23] <zazi> s/has/utilises
[07:23] <bigbluehat> mk_: darrelmiller: thanks, guys :)
[07:24] <bigbluehat> honored that you took the time to watch it :)
[07:24] <mk_> I'm using riak atm but you definitely made a good case for couch
[07:24] <mk_> riak is pretty cool though
[07:24] <bigbluehat> mk_: excellent :)
[07:24] <mamund> :)
[07:24] <bigbluehat> yeah, I've heard some good talks on riak as well
[07:24] <bigbluehat> different animals, but all good for the right use cases
[07:24] <mk_> the quorum stuff is aweesome
[07:25] <bigbluehat> quorum stuff?
[07:25] <mk_> as in the tune'able CAP stuff
[07:25] <bigbluehat> ah
[07:25] <mk_> where you can tune the W/R/N balance per bucket and even per request
[07:25] <bigbluehat> I've not dug into riak yet
[07:25] <bigbluehat> so what I know is from presentations
[07:25] <bigbluehat> wow…that would be handy
[07:25] <mk_> matias myer just released a book called Riak Handbook
[07:26] <mk_> highly recommended, it's well written and pretty comprehnsive
[07:26] <mk_> he works for basho so
[07:26] <mk_> bigbluehat: yeah it's very cool
[07:26] <mk_> means you can tweak/evolve your CAP depending on business requirements
[07:27] <mk_> 'CAP balance*' or whatver the terminology is
[07:27] <mk_> anyway, that's irrelevant - your talk was great
[07:28] <darrelmiller> What exactly do I charge to on my timesheet when participating in REST-Discuss threads?
[07:28] <mk_> good content, good delivery. was class.
[07:31] <fu-manchu> R&D
[07:32] <fu-manchu> Rest & Discuss
[07:32] <bigbluehat> mk_: thanks muchly. :)
[07:33] <bigbluehat> if you know of anyone out there looking for talks, etc on CouchDB or decentralized architectures, have'em e-mail/twitter/etc me
[07:33] mk_ nods
[07:46] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) joined #rest.
[07:55] <zazi> ... and another intents approach: http://intended-action.appspot.com/
[07:56] <zazi> see also http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0088.html
[07:57] <mk_> am I being dumb here
[07:57] <mk_> why could web intents not just be links with rels
[07:59] <zazi> cf. tomgibara's comment to this blog post http://paul.kinlan.me/web-intents-a-fresh-look
[07:59] <zazi> (... and because rels shouldn't be actions ;) )
[08:00] <mk_> I have no idea why people say that
[08:00] <fu-manchu> I finished reading http://intended-action.appspot.com/about and I intend to learn more so I follow the link to http://intended-action.appspot.com/about
[08:00] <fu-manchu> ;)
[08:01] <mk_> I don't like 'action' relations
[08:02] <mk_> but there's absolutely no reason that you can't use the semantics behind relations to describe 'activities'
[08:02] <mk_> you could have a set of rels for linking up a todo-list and its items
[08:03] <mk_> and then between the various rels describe what transitions can be made between them (i.e. a todo app)
[08:03] <zazi> from my POV, you mix two different things then
[08:03] <mk_> so what? :|
[08:04] <mk_> because of some arbitrary distinction between what something 'is' and what it 'does'
[08:04] <zazi> as you maybe know, I came from the Semantic Web, Linked Data, Knowledge Representation world
[08:05] <zazi> I reviewed, designed and utilised many ontologies/vocabularies
[08:05] <mk_> ontology is about being - not doing. most people aren't trying to model and analyse data - they're trying to get something done.
[08:05] <darrelmiller> fu-manchu: Perfect. That's exactly what I will do.
[08:06] <fu-manchu> :)
[08:06] <zazi> the binary relation/property bit in an RDF triple is usually not an action it is only an relation, i.e., a (X)HTML "next" relation would be "has next" etc.
[08:06] <mk_> zazi: these sorts of arbitrary rules are why I don't like touching RDF stuff
[08:07] <fu-manchu> it's not arbitrary; it perfectly follows Conway's Law for philosophy departments
[08:07] <mk_> lol
[08:08] <darrelmiller> I only like to expose to my client only the information it needs to perform its task. Exposing any more opens the door unnecessary coupling and can limit my future options.
[08:08] <zazi> since we are mapping these relations via RDFa into as values of the 'rel' attribute into (X)HTML, it seems a bit confusing to read, e.g., "name" side-by-side with "edit"
[08:08] <mk_> +a bajillion darrelmiller
[08:09] <darrelmiller> It's the reason why we have protect and private members on classes. It's not that those members are not valuable, they just don't need to be exposed.
[08:09] <zazi> so I would tend to say rel="name" action="edit"
[08:09] <mk_> :|
[08:10] <mk_> things really don't need to be that complicated.
[08:10] <mk_> I think RDF tech suffers a bit from living in an echo-chamber of people who all agree with each other
[08:10] <zazi> for it's not so complicated, just confusing, why I should put them together, but their nature is so different
[08:11] <darrelmiller> mk_: I agree ;-)
[08:11] <mk_> but don't connect with what every-day muggles like me (and the clients of my app) can fit in our little pea brains
[08:11] <zazi> :)
[08:11] <mk_> seriously.
[08:11] <mk_> rdf is too complicated.
[08:12] <mk_> you are trying to drink the sea with a fork.
[08:12] <darrelmiller> speaking of muggles, I just got downvoted on SO for suggesting WADL isn't needed for doing REST.
[08:12] <zazi> but there is no real alternative, which seems to be easier, because it is on the other side so natural
[08:12] <mk_> lol
[08:13] <fu-manchu> darrelmiller: paste the link and I'll counter-vote for you :)
[08:13] <darrelmiller> http://stackoverflow.com/questions/4068215/wadl-applications/4069803#4069803
[08:23] <zazi> "[17:04] <mk_> because of some arbitrary distinction between what something 'is' and what it 'does'" - exactly, this is the tipping point :: anyway, I have to further investigate on this topic ...
[08:24] <mk_> if you want an answer you'll probably have to spend 30 years up a mountain on your own
[08:24] <mk_> good luck with that.
[08:24] <mk_> :P
[08:25] <zazi> :D
[08:27] <mk_> I just try to figure out what I lose/gain by picking either position
[08:28] <darrelmiller> mk_: Do you have a decent response to the criticism that using rel to provide semantics of a resource makes the response message not self-descriptive?
[08:28] <zazi> btw, mk_, we are still waiting for your HAL answer on rest-discuss (as requested by mamund) ;)
[08:28] <darrelmiller> I've been sitting on a response for the last 8 hours and I can't make up my mind whether to post or not.
[08:28] <mk_> zazi: yeah sorry I completely forgot about that need to do it
[08:29] <mk_> darrelmiller: basically because that is a corrupt view of what self-descriptiveness'es value is
[08:30] <mk_> saying you 'lose self-descriptiveness' doesn't really mean anything unless you show what the *point* of the 'descipritiveness' that got dropped was in the first place
[08:30] <darrelmiller> So you agree that it is not self-descriptive. You just don't think it matters in this case because you have context.
[08:31] <mk_> well the kind of semantics that are important self-descriptively in the body are things that proxies do stuff with
[08:31] <mk_> which are all non-domain-specific
[08:31] <mk_> like ESI
[08:31] <darrelmiller> Ahhh. Gotcha.
[08:31] <darrelmiller> Not sure I agree, but at least I understand your perspective.
[08:32] <mk_> my view on self-descriptiveness is basically based on what the (holy) dissertation says
[08:32] <zazi> wasn't there at some time a differentiation between "self-descriptive" and "self-describing" (or something similar)?
[08:32] <darrelmiller> I also correlate self-descriptive with not requiring out-of-band info.
[08:32] <darrelmiller> zazi: Yeah but I ignored that.
[08:33] <mk_> "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability"
[08:33] <darrelmiller> I think that was relating to an entity body decribing itself. Self-descriptive is all about the message. IMHO.
[08:33] <mk_> since talking to mamund I wanted to write something about this in longer (blog) form
[08:33] <zazi> yep
[08:33] <mk_> but I don't want to steal mamund's thunder
[08:33] <mamund> you go right ahead mk_
[08:34] <zazi> *g*
[08:34] <mamund> :)
[08:34] <darrelmiller> mk_: So how do you feel about clients having out of band knowledge about a application/xml response?
[08:34] <mk_> I'm too scared I don't know what I'm talking about
[08:34] <mk_> :)
[08:35] <mk_> darrelmiller: personally I don't really care about that so much - the reason I promote hal is because I think interesting things will happen if/when everyone starts doing linking/embedding in the same way
[08:35] <mk_> at an application level - not a system level
[08:35] <mk_> from a self-descriptive pov in many cases the body is just a blob
[08:35] <mk_> but that's just my take on what that term means
[08:35] <darrelmiller> Out of band "application level" coupling is a big deal for me.
[08:36] <mk_> I'm talking about m2m stuff btw
[08:36] <darrelmiller> It's what allows a client to react to a response instead of expecting a response.
[08:36] <darrelmiller> ..of a certain type.
[08:36] <mk_> using HAL to reinvent html is fine but different kettle of fish to m2m stuff
[08:36] <darrelmiller> mk_: There's always a human.
[08:37] <mk_> .. :)
[08:37] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Quit: Leaving.
[08:37] <darrelmiller> Ok, I'll continue stewing on this.
[08:37] <mk_> the 'actor' at run-time is a machine though
[08:38] <darrelmiller> sure, following pre-canned instructions give to it by a human.
[08:38] <darrelmiller> It's just a matter of _when_ the human made the decision.
[09:02] <whartung> humns...don't trust 'em.
[09:02] <whartung> especially with decisions.
[09:06] <zazi> re. the naturality (?) of triples: "A link can be viewed as a statement of the form "{context IRI} has a
[09:06] <zazi> {relation type} resource at {target IRI}
[09:06] <zazi> ;) (from https://groups.google.com/group/hypermedia-web/msg/01fad6a3487be522)
[09:07] <mk_> btw the author of the web linking spec says "don't take it as gospel"
[09:08] <mk_> can't be bothered to find it but mnot said somewhere on a google+ thread that it was slapped together and a strict interp is not really necessary
[09:08] <mamund> mk_ zazi : that is my recollection, too.
[09:08] <mamund> FWIW, i did not get that kind of feedback from tantek celik
[09:08] <darrelmiller> So, is rel="customer" a thing or a relation ?
[09:09] <darrelmiller> rel="license" ?
[09:09] <zazi> I would say yes, because it is "has customer" and "has license" etc.
[09:09] <darrelmiller> yes it is a thing or yes it is a relation.
[09:09] <zazi> it's just a matter of "design" to cut the "has" (auxiallary) verb
[09:09] <mamund> 8] [@mamund(+i)] [2:freenode/#rest(+nt)]
[09:10] <mamund> [#rest] tantek was quite adamant that rels
[09:10] <zazi> it is a relation
[09:10] mamund is a dope, sorry
[09:10] <mamund> https://groups.google.com/forum/#!msg/hypermedia-web/9Y7M4bpyGZE/AN0F4DU30VQJ
[09:10] <darrelmiller> zazi: But no-one would blink at at an url like this /customer/34 Which makes it a thing too, no?
[09:10] <mamund> rel="maze" was rejected by tantek celik since it was not viewed as a proper rel
[09:11] <mamund> "abuse of @rel" was the phrase used<g>
[09:11] <zazi> the tipping point is, that you often get statement like: <#collection> <:item> </item/34>, where /item/34 is of type 'Item'
[09:12] <zazi> I guess, this was probably the case then, mamund
[09:12] <mamund> ?
[09:12] <darrelmiller> For me, rel is an identifier that provides the client with some instructions on how to deal with the link. It is just as opaque as an URL, IMHO. If you want to know what it means, read the spec.
[09:13] <zazi> darrelmiller, your example (/customer/34) would be a concrete thing then
[09:13] <zazi> mamund, something like <#something> <:maze> </maze/34>, where /maze/34 is of type 'Maze'
[09:13] <mamund> wait
[09:13] <darrelmiller> zazi: so if "customer" can be both a thing and a relation, how are we supposed to constrain rels to be only relations.
[09:14] <mamund> you are saying that rel="maze" is not a vlaid rel because...
[09:14] <mamund> it can be interpreted as a "type"?
[09:14] <darrelmiller> This is intellectual masturbation, IMO.
[09:14] <zazi> no, don't be confused
[09:15] <darrelmiller> ....if you will forgive the expression ;-)
[09:15] mamund is not sure who is not supposed to be confused
[09:15] <zazi> I argued that "customer" i the 'rel' position should be interpreted as "has customer"
[09:16] <mamund> zazi: is that directed at me? darrelmiller?
[09:16] <zazi> where the target resource is a _C_ustomer
[09:16] <darrelmiller> zazi: haha. Right. ok.
[09:16] <zazi> (the last to sentences were for darrelmiller)
[09:17] <darrelmiller> But rels are generally all lowercase, so then there is customer the thing and there is customer the relation. Which brings me back to my point that trying to make the distinction is futile.
[09:17] <zazi> "[18:14] <@mamund> you are saying that rel="maze" is not a vlaid rel because..." - no, I tried to say that "maze" could be a valid relation, which would usually be "has maze"
[09:18] <darrelmiller> zazi: So as long as we prefix all rels with "has" we're all cool ?
[09:18] <darrelmiller> rel="hascustomer" and rel="hasmaze"
[09:18] <zazi> no, I can give you some examples (in appr. 30 min, when I'm back, gtg now ...)
[09:18] <darrelmiller> me too. later.
[09:19] <mamund> "has"==ok, "is"==bad <g>
[09:32] zazi_ (~zazi@p5DDA99C3.dip.t-dialin.net) joined #rest.
[09:32] zazi (~zazi@p5DDA99C3.dip.t-dialin.net) left irc: Read error: Connection reset by peer
[09:32] zazi_ -> zazi
[09:43] <whartung> so am I a "has" or an "is"??
[09:44] bigbluehat (~bigblueha@adsl-74-177-98-159.gsp.bellsouth.net) joined #rest.
[09:51] <mk_> you're a way
[09:51] <mk_> of the universe to people
[09:51] <zazi> so back again, mamund, I guess, Tantek was confused about the rel "maze" because the referred resource was a resource of the Maze+XML media type
[09:53] dkubb -> dkubb|away
[09:55] dkubb|away (~dkubb@50.92.131.237) left irc: Quit: Linkinus - http://linkinus.com
[09:55] <hdave1> mamund: don't forget to send me the email to I can add the CXF stuff to the wiki
[09:56] <hdave1> mamund: I finished up reading your blog posts and have a quick (semi-philosophical) question for you
[09:57] <zazi> as other people pointed out in the referred thread, not all links need a rel attribute specified, the example above satisfies this aspect
[10:13] scott| -> _scott
[10:15] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) left irc: Quit: Leaving.
[10:16] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) joined #rest.
[10:28] caaakeeey (~caaakeeey@gatekeeper-ext.zeus.com) left irc: Quit: Leaving
[10:33] <mamund> hdave1: hey there!
[10:33] <mamund> sorry for dropping the ball on implementing-rest
[10:34] <hdave1> mamund: i am sure you have more important things to worry about ;-)
[10:36] <mamund> you should be all set now hdave1
[10:37] <hdave1> mamund: thx
[10:37] <mamund> np
[10:40] <mk_> mamund
[10:40] <mk_> actually anyone, really
[10:40] <mk_> any ideas what this means? http://twitter.com/Paul_Kinlan/status/157148039390302209
[10:41] <mk_> went over my head, I think
[10:41] <mamund> yeah, no clue there
[10:42] <mamund> i _suspect_ he means that minting a new element for _HTML_ means avoiding some pre-established behaviors for the existing LINK element.
[10:42] <mamund> just a guess, tho
[10:42] <zazi> I guess, that the rel must be defined somewhere and one has to process that knowledge before, i.e., de-referencing the URI of that rel
[10:42] <mamund> zazi: same applies to the intent identifier
[10:43] <mk_> :)
[10:43] <mk_> bingo.
[10:44] <zazi> yep, I read his arguement already some in the blog post from him that I posted earlier here
[10:45] <mk_> about why not to use link ?
[10:45] <zazi> or was it in the Web Intents FAQ
[10:45] <mamund> i like the idea behind WebIntents, but not sure i agree w/ the implementation plan.
[10:45] <mk_> me too
[10:46] <mk_> I wish html forms had a rel attribute.
[10:46] <mamund> it's really just another "CoD" pattern or "plug-in" thing.
[10:46] <mk_> well
[10:46] <mamund> mk_ yep, me too.
[10:46] <mk_> mamund: well I think for m2m
[10:46] <mk_> it's basically the way I view the best way to granulate applications
[10:46] <mk_> into 'intents'
[10:46] <mk_> for m2m
[10:46] <mamund> makes sense
[10:47] <mk_> but, personally I don't see a pressing need to formalise it
[10:47] <mk_> you just.. create link relations
[10:47] <mamund> it also seems close to the HAL pattern of expressing all semantics via a single identifier
[10:47] <mk_> that machiens navigate with their intention
[10:47] <mk_> mamund: right exactly
[10:48] <mk_> my problem with the "you can't use rels to do that"
[10:48] <mk_> is that it comes from a bunch of people who don't want any mess
[10:49] <mk_> becuase they're trying to build a perfect semantic zen-garden they can frolic in
[10:49] <mamund> essentially, this is "extensible" HTML
[10:49] <mk_> yeah that's also another problem I have with the 'intents' thing for GUI stuff
[10:49] <mk_> it's completely redundant, really
[10:49] <mk_> we already have forms that work just fint
[10:49] <mk_> fine^
[10:50] <mamund> this drops the adhoc HTML.FORM and adopts HAL's pre-defined args
[10:50] <mk_> right, I have no interest in trying to make html behave that way btw
[10:51] <mk_> HAL is meant to be about m2m stuff really
[10:51] <mamund> meh
[10:51] <mk_> although obviously darrelmiller is bent on reinventing HTML
[10:51] <mk_> with it
[10:51] <mk_> which is cool.
[10:52] <mk_> really for browsers we already have a CoD solution for injecting 'intents' that works awesome
[10:53] <mk_> it's used all the time for facebook like and google +1 buttons
[10:53] <mk_> or github gists, or disqus comments
[10:55] <mk_> and if you go up a level to the browser
[10:56] <mk_> you've got the 'subscribe to feed' intent that works just fine using html link
[10:56] <mk_> does that count as an 'intent'?
[10:58] <mamund> yeah, i;m not clear on what problem this solves.
[11:00] <hdave1> mamund: been reading your blogs....they are very good thank you
[11:00] <hdave1> mamund: have a question....
[11:00] <mamund> :)
[11:01] <mamund> give it a shot
[11:01] <hdave1> mamund: the relationship between a web browser and a web site is very decoupled....it is always pointed out WRT REST that I can do online banking or search for a map location and the browser has now prior knowledge of any of these sites
[11:02] <hdave1> I get that
[11:02] <hdave1> but the relationship between a client-consumer of a REST web service and the REST web services is not so decoupled
[11:02] <hdave1> take your list REST API for example from your blog
[11:03] <hdave1> my client still needs to understand what your "today" and "open" link relations are
[11:03] <hdave1> my client still needs to know that people like to see the "new" button to the left of the "delete" button, etc.
[11:03] <hdave1> in other words, a REST web service API *reduces* coupling, but cannot eliminate it...yes?
[11:04] <mamund> yes, elimination is not the goal of this style.
[11:04] <hdave1> ok -- that I did not know
[11:04] <mamund> pretty sure elimination is impossible, but ready to be proven otherwise
[11:04] <mamund> but ther eare a few things to point out here
[11:05] <mamund> client apps are "driven" by "someone"
[11:05] <darrelmiller> Limiting the coupling to link relations and media types is what I perceive to be the strategy.
[11:05] <hdave1> LIGHT BULB
[11:05] <mamund> darrelmiller: that's a good POV
[11:05] <darrelmiller> It's about managing and controlling the coupling, not eliminating it.
[11:06] <mamund> be aware of the coupling is a great start, actually
[11:06] <mk_> indeed.
[11:06] <mamund> making sure you recognize it when you see it,
[11:06] <mamund> know where you _want_ it to appear
[11:06] <darrelmiller> I have actually started taking it to an implementation level. I put my media type and link relation code in one set of DLLs that are separate to the client and server code.
[11:07] <mamund> darrelmiller: very cool
[11:07] <darrelmiller> That way, I know if I don't release a new version of the mediatype/linkrelation DLLs, nothing should break.
[11:07] <darrelmiller> If it does, I've coded something wrong on the client or server.
[11:07] <mk_> unless your hypermedia controls significantly improve your ability to evolve your application in a useful way - you are just increasing the various ways your clients can (and will) couple
[11:07] <mamund> hdave1: does this help?
[11:07] <mk_> and making your life harder in the future.
[11:07] <hdave1> darrelmiller: that is blowing my mind...that is cool
[11:07] <mamund> :)
[11:07] <hdave1> mamund: yes, this really helps me a lot
[11:08] <mamund> very cool
[11:08] <hdave1> I guess I got confused because firefox and google maps are totally decoupled...but that is because they both know how to properly deal with HTML media type...yes?
[11:08] <mk_> :)
[11:08] <mk_> precisely
[11:08] <mamund> well, not sure about the maps and all that....
[11:08] <hdave1> sure...lots of javascript in there, ect., etc
[11:09] <mamund> but the point is to identify where things are bound...
[11:09] <hdave1> firefox and ebay would be a better analogy
[11:09] <darrelmiller> The other nice thing about separating the code base for link relations and media types is that you can control who can change them.
[11:09] <hdave1> darrelmiller: do you do this in Java?
[11:09] <darrelmiller> .net
[11:09] <hdave1> tk
[11:10] <hdave1> ts/tk/k
[11:10] <mk_> it's more about the media type you pick
[11:10] <mk_> than anything
[11:10] <hdave1> so the more my application could learn to make good use of the HTML media type, probably the less javascript I need to be writing....
[11:10] <darrelmiller> Imagine a large corporation where the architecture group shipped around a DLL to all the teams that included parsers for "company approved" media types and link relations.
[11:10] <mamund> i;m working now on exploring the way we (as devs/archs) decide to map a problem domain to code/media-types
[11:11] <hdave1> because the browser could handle it directly
[11:11] <mamund> hdave1: yes, i think focusing on ways to map your problem directly to the media type (rather than just using MT as a container for js+data) is a good idea.
[11:12] <hdave1> in my app, we are manipulating complex object graphs most of the time (think electrical engineering or UML models)
[11:13] <hdave1> right now, our only media type is application/xml or application/json -- totally generic
[11:13] <hdave1> almost totally useless
[11:13] <mamund> :)
[11:13] <zazi> mk_, could you provide a human-readable explanation of the example in the HAL spec?
[11:14] <mk_> how do you mean ?
[11:14] <zazi> which explains the JSON/XML code
[11:16] <hdave1> I could imagine my team coming up with 5, 10, 15 media types for our different models "vnd" type stuff....roughly corresponding to XML Schema types we would use for SOAP payloads. Is this the right way to be thinking about media types, or am I still not getting it?
[11:17] <mk_> zazi: are you saying the examples are not clear ?
[11:17] <mamund> hdave1: i suspect you can use a single hypermedia type to express the client-server interactions you need to accomplish
[11:17] <mk_> hdave1: i.e. "here is a link you need to follow to x"
[11:18] <zazi> mk_, I'm saying adding a description (prosa) is always better
[11:19] <mk_> ok, I don't know if I'll be able to come up with something that doesn't sound really goofy :P
[11:19] <hdave1> mk_: meaning the media type is like application/vnd.entitygraph and use it to get from any single entity (entity graph) to its associated ones?
[11:20] <mk_> yes, and another common requirement is to indicate that the server has gone ahead and embedded another resource's content in the current content
[11:20] <mk_> e.g. with a list
[11:20] <zazi> mk_, e.g. is the URI of the examples,e.g., http://example.com/orders or http://example.com/orders/123 ? (I guess it is the latter one)
[11:20] <mk_> to save multiple requests
[11:20] <mk_> zazi: yea
[11:20] <hdave1> mk_: to solve the problem of excessive chattiness and performance
[11:20] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) left irc: Quit: Leaving.
[11:21] <mk_> right - but be able to represent that in a consistent way
[11:21] <hdave1> mk_: right
[11:21] <mk_> there is a type that does both of those things already
[11:21] <mk_> :)
[11:21] <hdave1> whats that?
[11:22] <mk_> it's called HAL
[11:22] <hdave1> what is the status of HAL?
[11:22] <mk_> draft
[11:22] <hdave1> any implementations?
[11:22] <hdave1> i saw someone was working on one from the website
[11:22] <mk_> it's got an active mailing list and couple of parsers available already
[11:24] <mk_> zazi: actually, I'm not sure I understood that question
[11:26] <mk_> the URI of the root resource (i.e. the target of the request) is http://example.com/orders, and the embedded orders' are http://example.com/orders/...
[11:27] <zazi> mk_, which URI could lead me to examples of the HAL spec: e.g. http://example.com/orders or http://example.com/orders/123 ?
[11:27] <zazi> okay, thx
[11:27] <mk_> the root resource has an implicit rel="self"
[11:27] <zazi> yep, I think I got it
[11:28] <hdave1> mk_: ok...need to go to school on HAL
[11:29] <hdave1> mk_: will start by reading the group archives
[11:29] <mk_> I wrote it btw
[11:29] <mk_> the spec
[11:30] <mk_> so my opinion isn't exactly neutral
[11:35] <mk_> mamund: this disucssion about LE === LO would be a lot easier for me if the pre-fetched transclusion was separate from LE
[11:35] <mk_> :)
[11:36] <mk_> infact
[11:36] <mamund> hmmm...
[11:36] <mk_> I actually agree with the guys saying there isn't a distinction, /apart/ from the pre-fetched instance
[11:37] <mamund> why does prefetching matter here?
[11:37] <mamund> this is about _timing_?
[11:37] <mk_> exactly
[11:37] <mk_> well
[11:37] <mk_> I guess your saying it isn't
[11:38] <mk_> but the mechanical difference between LE and LO is basically a trivial thing that the client decides based on its use case
[11:38] <mk_> maybe not, I don't know
[11:38] <darrelmiller> mk_: How does it feel to be wrong for once ? ;-)
[11:39] <mk_> for me it's an accident of history that HTML has differnet types of link for 'embedded' stuff and outbound stuff
[11:39] <mk_> i.e. html could just have well have been <link rel="anchor" and <link rel="image" vs. <a> and <img>
[11:40] <mk_> they're effectively the same fundamental hypermedia control just applied in a different way
[11:40] <darrelmiller> sure I agree it doesn't matter how the distinction is communicated, but the distinction is still significant.
[11:40] <mk_> *apart* from when you are talking about a hypermedia control that is capable of indicating some content is literally 'embedded' in teh response
[11:42] <darrelmiller> mk_: Do you not think it is significant the fact that the URL changes in the address bar when a LO is dereferenced but it is not when a LE is dereferenced?
[11:42] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Quit: Wombert
[11:42] <mk_> not in an m2m context, no
[11:42] <mk_> well
[11:43] <mk_> it might be, but I wouldn't attribute that to the hypermedia control itself
[11:43] <mk_> that's some facet of an application
[11:44] mamund was away
[11:44] <darrelmiller> Meh, I don't care about the hypermedia control. I care about the impact it has on the client state,
[11:45] <mamund> darrelmiller: yep
[11:45] <mk_> right but what you're really talking about is another factor that already has a name
[11:45] <darrelmiller> LE and LO are different and the server dictates which ones make sense for a particular resource.
[11:45] <mk_> relation control
[11:45] <mk_> that is my point - there already is a factor for that
[11:45] <mamund> the factors i identified are not limited to _protocol_ details
[11:45] <darrelmiller> mk_ which one is that?
[11:45] <mamund> they are a set of basic affordances
[11:45] <darrelmiller> I don't see a "relation control" H-Factor
[11:45] <mk_> CL
[11:46] <mamund> mk_: right
[11:46] <mk_> so the real difference between <a> and <img> is actually CL
[11:46] <mk_> determined by CL rather
[11:47] <mamund> mk_: i think you're mixing details here
[11:47] <mk_> that kind of 'embed' is actual an application pattern
[11:47] <darrelmiller> I perceived CL to be a way of layering addition semantics onto a link over and above the other H-Factors.
[11:47] <mk_> you mean like embed semantics ?
[11:47] <mk_> :)
[11:47] <darrelmiller> e.g. CM is defined by the link relationtoo.
[11:48] <darrelmiller> CR stuff could be specified in the link relation spec so that it does not need to be explicitly included in the link.
[11:48] <mk_> "The H Factor of a media-type is a measurement of the level of hypermedia support and sophistication of a media-type"
[11:48] <mk_> LO + LE == LO
[11:48] <mk_> => LE == 0
[11:49] aGHz (~Adium@modemcable048.88-80-70.mc.videotron.ca) joined #rest.
[11:49] <mamund> ??
[11:50] <mk_> LE (apart from the boundary thing) doesn't do anything you can't do with LO (and CR)
[11:50] <mamund> ahh
[11:50] <mk_> so if it's a measurement of sophistication of the *media type*
[11:50] <mamund> well, that assumes you overload CR w/ a particular bit of information
[11:50] <zazi> https://gist.github.com/1596413 ;)
[11:50] <darrelmiller> mk_; See I disagree with that.
[11:51] <mamund> the point of the HFactors is to identify the _means_ by which things can be communicated.
[11:51] <mk_> zazi: yeah, that is ugly as hell.
[11:51] <mk_> :|
[11:51] <mamund> yes, you can use various means to get to a single end.
[11:51] <zazi> mk_, that'S your opinion :)
[11:51] <mamund> "how can i tell the client to transclude something"?
[11:51] <mk_> well turtle has been around for a while
[11:51] <mamund> "how can i tell the server which procotol method i want to use?"
[11:51] <zazi> I think it's bettern than always writing _self, _embedded, etc.
[11:51] <darrelmiller> If a media type supports rels, is it not possible to support all H-Factors using the rels?
[11:52] <mamund> yes, you can do that.
[11:52] <mamund> you can support all the _means_ using a wide variety of designs
[11:52] <darrelmiller> zazi: I wrote a hal parser in a few hours and a few hundred lines of code. Is the same possible with that representation?
[11:52] <mk_> LE vs LO actually makes no significant odds to the shape of the request
[11:53] <mk_> only the client interpretation of the response
[11:53] <mamund> the examples are just that _examples_
[11:53] <mamund> i guess i need to dust of my hypermedia design that uses only _one_ control
[11:53] <zazi> darrelmiller, I guess it depends on the skills of the programmer ;)
[11:53] <darrelmiller> mk_: The rel value makes no difference to the request either. It only affects the clients interpretation.
[11:54] <mk_> zazi: that's not a good answer when people are trying to build systems that are consumed by other people
[11:54] <mk_> even if darrelmiller was the best programmer in the world (which he may well be) his clients are still the ones writing the code against his application
[11:55] <mk_> a sad reality RDF serializations fail to overcome
[11:55] <zazi> darrelmiller, can I see the code of that parser?
[11:55] <mk_> it's all very neat and tidy, it's just not very simple or focused on the practical requirements most people have when exposing applications to other people they either don't know/control
[11:55] <darrelmiller> zazi: http://hal.codeplex.com/
[11:56] <zazi> thx
[11:56] <darrelmiller> Most of the serialization stuff is here http://hal.codeplex.com/SourceControl/changeset/view/8926d9d2d35f#Hal%2fHalSerializationExtensions.cs
[11:56] <mk_> mamund: you remember HAL was just one link element originally right - is that what you meant ??
[11:57] <mk_> anyway back to that point about LE
[11:57] <mamund> well, when you started that i challenged whether it made sense<g>
[11:57] <mamund> so, do test my theory, i worked on a design that used a single hypermedia control
[11:57] <mk_> darrelmiller: all the control data for embed is inline with a rel="embed" or rel="image"
[11:57] <mamund> but still offered _all_ the hfactors
[11:58] <mk_> that isn't the same thing for a 'fat' rel that's telling a client to POST somewhere
[11:58] darrelmiller wonders if he can find someone to do his work for him because this is way more fun.
[11:58] <mk_> that's a different thing
[11:58] <darrelmiller> mk_: Why is that different?
[11:59] <mk_> well because the control ceases to be in the representation
[11:59] <mk_> there's nothing 'wrong' with that
[12:00] <mk_> actually wait I'm wrong
[12:00] <darrelmiller> mk_: I told you.
[12:00] <mk_> :)
[12:01] <mk_> hmmm I can't figure out what that specific distinction is but I'm pretty sure there is one
[12:02] <mk_> actually no I'm not, I'm just full of shit
[12:02] <mk_> damn.
[12:04] <mk_> I guess my frustration is that the distinction just isn't really that interesting-a-type of embedding
[12:04] <mk_> and that the 'boundary' distinction is
[12:04] <mk_> but kind of gets lost/overlooked/not even really mentioned
[12:06] <darrelmiller> :-) For me I don't really care about the PALE scenario, I only care about the ALE scenario
[12:06] <mk_> already forgotten what those acronmys mean
[12:06] <mk_> oh passive blablabla
[12:06] <mk_> got it
[12:06] <darrelmiller> PAssive Link Embed and Active Link Embed
[12:06] <mk_> it came back to me
[12:08] <mk_> darrelmiller: so with hal would you do ALE via a link and a rel or would you want a self-closing resource to do that? or the choice of both ?
[12:08] <darrelmiller> By default I would use a link. I'm not really fussy though.
[12:09] <darrelmiller> In fact a <resource> is more likely to be a LO.
[12:09] <mk_> wahhh? :S
[12:10] <darrelmiller> I'm looking at an order with it's list of items and then I want to drill down to look at an single item. That would be a LO.
[12:11] <darrelmiller> An LE would be a stylesheet that allows me to visualize the order. I would never want to navigate to it.
[12:11] <zazi> mk_, what do I get if I de-reference, e.g., /orders/123?
[12:12] <mk_> zazi: no guarantees
[12:12] <mk_> the rel will tell you that
[12:12] <mk_> the contents of the resource that are embedding give you no guarantee about correesopndence
[12:12] <darrelmiller> and the content-type of the response :-)
[12:12] <mk_> darrelmiller: I've taken that out of the json representation for now
[12:12] <darrelmiller> ...together, working in harmony
[12:13] <darrelmiller> huh? Taken out what?
[12:13] <mk_> being able to embed another content-type
[12:13] <zazi> mk_, then it might be useful if you could provide definitions of the rels of your example
[12:13] <mk_> at least, I took it out of the example
[12:13] <darrelmiller> yeah, but zazi, said dereference. Which means make a HTTP request. So he would get a content-type back.
[12:14] <mk_> oh I see
[12:14] <mk_> yeah, sorry :)
[12:14] <darrelmiller> phew.
[12:14] <zazi> yep
[12:19] KevBurnsWork -> KevBurnsJr
[12:20] <KevBurnsJr> Good afternoon
[12:21] <whartung> howdy KevBurnsJr
[12:24] <mamund> KevBurnsJr!
[12:25] <mamund> KevBurnsJr: like th tweeted quote, btw
[12:30] <darrelmiller> I'm pulling out the big guns now. http://old.nabble.com/Re%3A-Unifying---standardizing-X-Moz---X-Purpose-headers-p29794338.html
[12:31] <darrelmiller> Fielding differentiates between a passive request (inline image, stylesheet) and an active request in Waka.
[12:32] <mamund> yes, i recall this.
[12:32] <mamund> this strikes me as an optimization
[12:32] <mamund> of LO
[12:33] <darrelmiller> strikes me as a distinction ;-)
[12:33] <mamund> so, you figure prefetch is the distincion?
[12:34] <mamund> or something else?
[12:34] <darrelmiller> No prefetch is just a different way of treating LEs.
[12:34] <mamund> so you figure the prefetch does not operation on navigation links, only transclusion links?
[12:35] <darrelmiller> hmmm.
[12:35] <darrelmiller> no, looks like you could do prefetch on any link as long as it is Safe and Idempotent.
[12:35] <mamund> yep
[12:36] <mamund> to me this, then, is about timing only. _when_ you resovle the link.
[12:36] <darrelmiller> Prefetch yes.
[12:36] <darrelmiller> But the notion of passive is equivalent to an LE, no?
[12:39] <mamund> Q,q,f
[12:39] <darrelmiller> Q=LO q=LE
[12:39] <mamund> yep, i think so
[12:40] <mamund> then f he leaves open (no active/passive distinction)
[12:40] <mamund> so that's why i think of this as an optimization.
[12:40] <darrelmiller> Right because it doesn't matter because you are not changing the current client state.
[12:40] <mamund> right
[12:40] <mamund> pre-caching
[12:41] <mamund> etc.
[12:45] <zazi> btw, I do not need to implement a Turtle parser, they are already out there :)
[13:16] talios (~textual@akl.smx.co.nz) joined #rest.
[13:22] <Ngarthl> but implementing parsers is fun :) hehe
[13:24] <darrelmiller> Ngarthl: Oh, will you implement a SQL parser for me. I need one of those.
[13:25] <Ngarthl> wrong platform ;)
[13:25] <whartung> He doesn't care, he'll port it...
[13:25] <darrelmiller> Sure, no problem.
[13:28] talios (~textual@akl.smx.co.nz) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[13:28] talios (~textual@akl.smx.co.nz) joined #rest.
[13:32] <Ngarthl> heres a paper http://www.cunei.com/cwu-scala-sql.pdf
[13:32] <mamund> yipes!
[13:34] <whartung> heh nice
[13:38] <hdave1> I thought that media types in HTTP were supposed to be (according to the HTTP spec) only about format. Kind of like the extension of a file on a file system. Yet it seems like folks are creating new media types that absorb domain specific concepts.
[13:38] <hdave1> like finance, purchasing, math, etc
[13:38] <whartung> media types are not semantics.
[13:39] <mamund> hdave1: not sure of what you are sayhing here/
[13:39] <mamund> you say HTTP spec talks about the limits of what MIME media types should represent?
[13:39] <hdave1> yes
[13:39] <mamund> where is that?
[13:39] <hdave1> on sec....
[13:39] <mamund> cool
[13:40] <talios> hdave1 - yep, thats what something like HAL is trying to address IMHO, the format is not the interpretation.
[13:41] <hdave1> right -- because you can infer the semantics of the response by using the link relation you used to get the response in the first place
[13:41] <hdave1> the semantics are in the link relation
[13:41] <darrelmiller> whoa.... That's not the only way.
[13:41] <mamund> first, still waiting on the pointer..
[13:41] <darrelmiller> There is nothing wrong with putting semantics in the media type.
[13:41] talios still disagrees with "semantics in the link rel"
[13:41] <mamund> second, "the semantics" is sufficiently vague here
[13:41] <hdave1> mamund: -- struggling to find it...was buried as a quote from the spec in the "The "new media types are evil" meme" thread
[13:42] <mamund> LOL
[13:42] <whartung> I have avoided that thread pretty much completely lol
[13:42] <mamund> ok, well, let me know when you find it.
[13:42] <mamund> skeptical mamund is skeptical<g>
[13:42] <whartung> Its like looking atmy in box and see a phone book. "Um..no."
[13:42] <whartung> I tire just looking at it...
[13:42] <hdave1> mamund: will do (sigh) ... now my limited credibility is on the line
[13:43] <mamund> now, from the app-protocol POV (HTTP), it does not _matter_ what the body represents.
[13:43] <mamund> the protocol is interested in the _message_ (headers+body)
[13:43] <hdave1> darrelmiller: if semantics (like purchase-order, stock-quote, etc.) can be in a media-type then that makes my life a lot easier
[13:43] <mamund> and, for the most part, ignores the body (just passes it along as requested)
[13:43] <mamund> finally, not even sure why this has come up.
[13:44] <darrelmiller> hadave1: In the short term yes. But be careful there are pitholes there too,
[13:44] <mamund> is ther something you suspect is happening in media types that is problematic for the protocol? network? ,etc?
[13:44] <hdave1> It seems like a lowly guy like me has no business defining new HTTP media types
[13:44] <mamund> LOL
[13:44] <hdave1> could be a self-confidence thing ... ;)
[13:44] <mamund> ok, but why?
[13:44] <whartung> no, hdave1, they actually don't make it any easier. This is a false hope.
[13:45] <Ngarthl> REST is simple, but not easy ;)
[13:45] <talios> :)
[13:45] <whartung> Ohh...I'm tatooing that on my left thigh.
[13:45] <mamund> ouch
[13:45] <mamund> _outer_ thigh, i hope
[13:45] <Ngarthl> follow up on that: http://www.infoq.com/presentations/Simple-Made-Easy
[13:45] mamund sturggles to get an image out of his mind now....
[13:46] <hdave1> My client needs to get entities from my server and each entity has a very unique presentation and editor....
[13:46] <whartung> yea, I have your likeness on my inner thigh mamund ... so there's no more room.
[13:46] <Ngarthl> whartung: haha
[13:46] <talios> Ngarthl: Rich has made "complect" my favorite new old word :)
[13:46] <darrelmiller> hdave1: Rember the original intent of rest is to make managing coupling easier. Creating a new media type for every business entity in your system may not make managing coupling easier.
[13:46] <whartung> complect? That's a real word?
[13:47] <hdave1> darrelmiller: I agree...I don't want to, but my client *needs* to know what is has so it can present it in the right way...
[13:47] <mamund> whartung: ahhhh!
[13:47] <whartung> It can look inside of it to know what it is.
[13:47] mamund runs away
[13:47] <hdave1> like a browser needs to know a jpeg is different from a video
[13:47] <Ngarthl> whartung: http://www.thefreedictionary.com/complect
[13:47] <hdave1> whartung: i thought that was a REST no-no
[13:47] <darrelmiller> hdave1: No. You don't need to know that a number is a bank balance in order to _present_ it.
[13:47] <whartung> ooh
[13:48] <hdave1> darrelmiller: i do if bank balances need a certain color, font size, and other special treatment
[13:49] <Ngarthl> then you have the context in which why you made the request in the first place hdave1
[13:49] <hdave1> whartung: if I look at the "payload" to figure out what it is, then I had to have out-of-band knowledge, yes?
[13:49] <talios> If we gave up on JSON and just used XML we could simply use namespaces and namespace declarations. Thats pretty much solves all these "whats my vocabulary" arguments.
[13:49] <mamund> hdave1: so you're talking about what a _client_ needs to know about the body, right? not the network, not the protocol.
[13:49] <hdave1> right
[13:49] <darrelmiller> Nope. Consider HTML's class="BankBalance" HTML knows nothing about banks.
[13:49] <mamund> well, of _course_ the client looks at the body, right?
[13:49] <darrelmiller> but it can still make it look pretty.
[13:50] <talios> Ngarthl - my argument against that is just cause I followed a link to get a BankBalance, doesn't neccessarily mean I got a BankBalance resource in return.
[13:50] <mamund> that's the whole point, eh?
[13:50] <whartung> I have two favorite examples. One is Roys GIF example. THe other is an Autocad example I encountered years ago.
[13:50] <Ngarthl> talios: true that.
[13:50] <talios> that's counter to "the resource is self descriptive" IMHO.
[13:50] <mamund> hdave1: am i missing something?
[13:50] <darrelmiller> talios: My point is that you do not need to communicate those semantics to the client. The client doesn't need them.
[13:51] <hdave1> mamund: yes, we need to get the body to do anything, but how can my client "process" these bodies differently without know what they are?
[13:51] <mamund> ohhhh
[13:51] <mamund> i see
[13:51] <mamund> so this is not about HTTP, etc. but about media type design and implementating a client, then, right?
[13:51] <hdave1> right
[13:51] <mamund> cool
[13:51] <whartung> The GIF example taht Roy used was to use the GIF format to represnet 10,000 bits of information -- a bunch of true false stuff. If you looked at it as an image, presented on a page, it was garbage. But that's not what the semantics were of the data -- it was not meant to be displayed.
[13:51] <mamund> 1) "know what they are"
[13:51] <mamund> tell me what you mean here?
[13:51] <hdave1> i bought your book, but I don't have it yet...btw
[13:52] <mamund> LOL
[13:52] <mamund> npo
[13:52] <Ngarthl> could we start calling a client a user agent? a client is a connector in REST terms
[13:52] <whartung> The GIF was just an efficient, well know format to transfer the bits.
[13:52] <mamund> what is it you think the client "needs to know" in order to "process" it?
[13:52] <whartung> In the autocad example
[13:52] <mamund> it== representaiton
[13:52] <whartung> we had an engineer take radar profiles off of 3-view drawing of airplanes.
[13:52] <hdave1> my client says - get me all heat producing elements on this circuit board (a kind of query)
[13:52] <talios> darrelmiller - I still don't see that. The client surely needs to know how to process a BankBalance resource's content, so it needs to know that its a BankBalance ( you're argument is that knowledge is via the link rel, but what if you never followed a link?
[13:52] <whartung> Viewed as a "technical drawing", it was a bunch of meaningless squiggly lines.
[13:53] <whartung> but used in context, with his program, it was radar data.
[13:54] <darrelmiller> talios: despite my support of MikeKelly and the semantics via link relations, I still don't see the need to bring business domain semantics down to the user-agent in 90% of cases.
[13:56] <whartung> most clients don't do content negotiation -- most simply don't bother. "Give me stuff in XYZ format, kthx".
[13:56] <talios> you must be doing something vastly different to me then :) How else does a client application process or deal with resource content?
[13:56] <whartung> when the client makes the request, it KNOWS what it wants, that's why it's making the request
[13:56] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) joined #rest.
[13:56] <whartung> it's not a random query with a random answer.
[13:56] <whartung> If I send back the answer "Green", that's a meaningless answer. What was the question?
[13:57] zazi (~zazi@p5DDA99C3.dip.t-dialin.net) left irc: Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?
[13:57] <whartung> but if I ask "what color is the light" and get "green". Aha!
[13:57] <whartung> now it makes sense.
[13:57] <Ngarthl> "what is the colour of magic", "Ocatarine" ;)
[13:57] <whartung> CLients don't make requests out of the blue just for fun because bandwidth is available. They know the context that they are in. So they know what they are expecting.
[13:57] <talios> darrelmiller - if an Android, or Windows Phone 7 app reads a resource, how else does it parse that and present that in GUI controls without knowing the semantics of what its processing?
[13:58] <talios> whartung - not in a world of websockets and push.
[13:58] <whartung> once they get their response, they process it. They pull out the gems of information that they're interested in.
[13:58] <talios> or, not neccessarily.
[13:58] <whartung> that's an async scenarios talios, and obviously there must be some mechanism of communicating context within the payload -- a mechanism the client knows how to use.
[13:59] <whartung> "Gren" "blue" 14 "Washington DC"
[13:59] <darrelmiller> talios: a UI, a chunk of data and a databinding document.
[13:59] <whartung> all valid answers...to...something.
[13:59] <darrelmiller> The databinding document is processed by the client and tells the UI where to display what content from the chunk of data.
[13:59] <whartung> with a synchronous request, the client maintains its own context. With an async one, it has to come in the payload.
[14:00] <talios> whartung - thats part of what's been argued for say vocab in HAL, or itemtype in microdata. context is in the payload, not an external rel
[14:00] <darrelmiller> there is two way binding. User updates are captured and sent back to the server for processing.
[14:01] <talios> darrelmiller - true, but surely the document should identify what databinding to use - i.e. self descriptive, not some external link rel.
[14:01] <whartung> there's no reason for that to be in the HAL standard. Because the HAL standard lets applications manage that themselves. Why standardize it? Why populate context info for a payload that doesn't need it?
[14:01] <whartung> IT's not HALs job to maintain that information.
[14:02] <talios> so HAL is not self descriptive then. w00t.
[14:02] <whartung> now, perhaps, this is a weakness in http.
[14:02] <whartung> for example, in http
[14:02] <talios> it tells you where to go, but not what it contains.
[14:02] <darrelmiller> talios: Why? The data document can stand alone. There is a LE to go get the databinding doc if you want to.
[14:02] <whartung> we have a referer header which is useful to the SERVER, but referrer is not defined (I don't think) for results, is it?
[14:02] <whartung> otherwise that's a great place to stuff context in HTTP.
[14:03] <whartung> it is optional for results?
[14:03] <whartung> because context in this case is not a resource state, right? it's conversational as part of the transcation. An invoice is an invoice whether deleviered sync or async.
[14:03] <talios> darrelmiller - mmm, good point - so maybe, <link rel="vocab" href="….."/> to be a RECOMMENDED way of expressing vocabulary? I'm down with that.
[14:04] <talios> standardise on the usage of rel="vocab".
[14:04] <whartung> so the invoice res rep should change to add in context info.
[14:04] <whartung> How do you insert that in to a JOEG for example.
[14:04] <darrelmiller> Ok, I can see that as a way of optionally supporting clients that really do want to know the detailed semantics.
[14:04] <whartung> JPEG
[14:05] <darrelmiller> talios: That's really what rel="profile" is for also.
[14:05] <talios> darrelmiller - hrm, I don't see that in the iana registry, is that spec'd anywhere? ( http://www.iana.org/assignments/link-relations/link-relations.xml )
[14:06] <talios> that woud keep me happy.
[14:06] <darrelmiller> http://microformats.org/wiki/rel-profile
[14:06] <darrelmiller> hmm, page is blank for me at the moment.
[14:06] <talios> doh
[14:07] <darrelmiller> weird
[14:07] <darrelmiller> whoa. The entire microformats site has gone.
[14:08] <whartung> whoops
[14:08] <darrelmiller> So much for using that over IANA as the link rel registry!!!!!
[14:08] <talios> rel="service" could work I guess - "Indicates a URI that can be used to retrieve a service document." "When used in an Atom document, this relation type specifies Atom Publishing Protocol service documents by default. Requested by James Snell."
[14:08] <talios> which is IANA
[14:09] <darrelmiller> A service doc is not the same thing.
[14:09] <talios> rel="glossary" - Refers to a glossary of terms. <- sounds perfect.
[14:10] <darrelmiller> here is the cached version of rel profile http://webcache.googleusercontent.com/search?q=cache:WV8fR2GkjqIJ:microformats.org/wiki/rel-profile+rel-profile&cd=1&hl=en&ct=clnk&gl=ca
[14:10] <talios> "Refers to a document providing a glossary of terms that
[14:10] <talios> pertain to the current document."
[14:12] bigbluehat (~bigblueha@adsl-74-177-98-159.gsp.bellsouth.net) left irc: Quit: Leaving.
[14:16] burngreg (~greg@203.84.135.124) joined #rest.
[14:17] <talios> I think adopting <link rel="glossary"/> should suffice.
[14:31] <talios> silence. I guess that solved all the worlds REST issues ;)
[14:31] <talios> either that or I got disconnected.
[14:31] <whartung> Yea, it's a lot easier to edict changes when there are fewer people on too...
[14:32] <talios> "Netsplits - assisting policy change review since 19xx"
[14:35] <whartung> "Yea I changed everything last night at 2am...nobody said anything so I figured it was ok..."
[14:38] <talios> darrelmiller - have you looked much into the rev attribute? Seems to be the reverse of the rel. i.e. rel identifies the outgoing relationing, rev the incoming. in that way - you could have <resource rev="customer">...
[14:38] <talios> still using link relation semantics, its just the "where" that gets expanded
[14:38] <darrelmiller> I've heard of it. I haven't really ever come across a scenario where I thought, hey this would be useful.
[14:39] <darrelmiller> yeah, I supposed you could do that in hal.
[14:39] <darrelmiller> s/supposed/suppose
[14:43] <talios> as a purely optional thing for those ( i.e. me ) who care ;p heh.
[14:49] aGHz (~Adium@modemcable048.88-80-70.mc.videotron.ca) left irc: Quit: Leaving.
[15:01] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Quit: Wombert
[15:19] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) joined #rest.
[15:20] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) left irc: Remote host closed the connection
[15:20] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) joined #rest.
[15:25] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) left irc: Ping timeout: 268 seconds
[15:46] talios (~textual@akl.smx.co.nz) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[15:47] talios (~textual@akl.smx.co.nz) joined #rest.
[15:48] pezra (~Adium@webmail.openlogic.com) left irc: Quit: Leaving.
[17:40] <talios> microformats site back online ;)
[17:40] <darrelmiller> I saw that.
[17:40] <darrelmiller> No response from @t though. I wonder what happened.
[17:42] <talios> not sure - via a nest of twitter followers someone got hold of someone
[17:42] <talios> I wonder if a domain reg was forgotten :)
[17:58] KevBurnsJr (~KevBurnsW@50.0.103.39) left irc:
[18:20] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) left irc: Ping timeout: 244 seconds
[18:58] dkubb (~dkubb@S010600212986cc6c.va.shawcable.net) joined #rest.
[19:43] talios (~textual@akl.smx.co.nz) left irc: Quit: to the cloud!
[20:02] burngreg (~greg@203.84.135.124) left irc: Ping timeout: 240 seconds
[20:19] burngreg (~greg@121.98.184.176) joined #rest.
[20:26] dkubb (~dkubb@S010600212986cc6c.va.shawcable.net) left irc: Quit: Leaving...
[20:28] dkubb|away (~dkubb@S010600212986cc6c.va.shawcable.net) joined #rest.
[20:30] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) joined #rest.
[21:50] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) joined #rest.
[21:51] talios (~textual@ip-118-90-11-129.xdsl.xnet.co.nz) joined #rest.
[21:55] dkubb|away (~dkubb@S010600212986cc6c.va.shawcable.net) left irc: Quit: Linkinus - http://linkinus.com
[22:08] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) joined #rest.
[22:36] dkubb (~dkubb@50.92.131.237) joined #rest.
[00:00] --- Thu Jan 12 2012