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

[00:01] Blazeix (~Blazeix@71.74.190.197) joined #rest.
[00:07] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:07] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[00:44] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving...
[00:57] Hakon|mbp (~hakon1@22.84-49-55.nextgentel.com) joined #rest.
[01:21] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[01:35] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[01:46] caaakeeey (~caaakeeey@gatekeeper-ext.zeus.com) joined #rest.
[02:06] Hakon|mbp (~hakon1@22.84-49-55.nextgentel.com) left irc: Quit: Leaving...
[02:33] zazi (~zazi@p579D3D60.dip.t-dialin.net) joined #rest.
[02:49] <zazi> mk_, I had a look at your SHAL proposal at https://gist.github.com/893552
[02:49] <mk_> that is very rough btw, it was a first pass at coming up with something
[02:49] <mk_> what did you think ?
[02:50] <zazi> it looks very good so far, and is appr. exactly what I had in mind for realizing the template type
[02:51] <zazi> 'template-type' is then the content-type of the template resource?
[02:53] <mk_> kind of - it's really just a URI that everyone can agree on for a particular type of template
[02:54] <mk_> not all templates have media types or will get registered
[02:54] <mk_> so letting people use URIs keeps things nice and flexible
[02:54] <mk_> they don't actually have to be URIs really, can just be any token
[02:55] <zazi> okay
[02:55] <mk_> i.e. template-type="http://mustache.github.com/";
[02:55] <mk_> or whatever
[02:56] <mk_> does mustache have a media type ?
[02:57] <mk_> I've seen underscore templates embedded in script tags with type="text/template" or similar
[02:57] <zazi> I think a template resource itself should have a media type
[02:58] <zazi> yep, makes sense
[02:58] <mk_> rght - I think that's a job for mustaahe guys etc.
[02:58] <mk_> I don't actually want to invent a templating language if I can avoid it
[02:58] <mk_> I think re-using mustache as a default makes the most sense afaict
[02:59] <mk_> wide language support already.. relatively logic-less
[02:59] <mk_> as I said on the mailing-list I'm not writing this up yet
[03:00] <mk_> I really want to get mamund and Ian Robinson's input
[03:00] <mk_> and guys like Jon Moore, those kind of people
[03:01] <zazi> maybe, I'll play around with this today and try to think about the worflow in m2m usecase
[03:01] <mk_> cool, let me know what you come up with
[03:03] <zazi> I think the template that would be filled could be some mustache annotated Turtle or JSON-LD as well, or?
[03:03] <mk_> yeah you could totally mint a new URI to do that
[03:03] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[03:04] <zazi> because in the m2m use case you do not have to fill HTML templates ;)
[03:04] <mk_> well mustache templates still have names for the variables :|
[03:05] <mk_> they are already machine templates..
[03:05] <zazi> but "Mustache is a logic-less templating system for HTML"
[03:06] <mk_> well afaict it's just logicless templates
[03:06] <mk_> people use it for html but you could use it to generate content any text-based media type
[03:07] <zazi> yep, that's what I thought as well
[03:08] <mk_> oh sorry I think I mis-understood what you said
[03:09] <mk_> I thought you meant create a new turtle-annotated-mustache tempalting system
[03:09] <mk_> but you just meant use mustache to create turtle
[03:09] <zazi> yep
[03:09] <mk_> yeah that is pretty much exactly the thinking behind that SHAL design
[03:10] <mk_> but I'd expect most people using SHAL would be generating HAL/SHAL documents with it :)
[03:10] <zazi> (one could do the latter one as well, however, I guess, this is not required atm :) )
[03:11] <zazi> hm
[03:12] <mk_> zazi: right, I don't expect anyone using HAL to want to do that :P
[03:14] <zazi> hm, maybe I get something wrong, but the result in your example is of the type "application/xml"
[03:15] <zazi> following your writings is should be "application/hal+xml" and the template should include some HAL tags and attributes, or?
[03:18] <zazi> I think "widget" is a bit misplaced in a m2m context, or?
[03:23] <zazi> one could maybe replace the 'control' tag with, e.g., 'template' as well
[03:28] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[03:31] <zazi> the 'control' element is btw LE (re. the template) and LO (re. filling the template) at once?
[03:32] <mk_> yeah I guess so
[03:32] <mk_> yeah maybe renaming it to template would make sense
[03:39] <zazi> maybe I'm dumb, but where comes the data from to fill the template? (in the m2h use case this would be entered from a human being)
[03:40] <zazi> in the m2m use case this must be processed by the machine agent
[03:42] <mk_> yeah
[03:42] <zazi> i.e. in the case of mustache the client needs to provide a yaml file
[03:42] <mk_> well depends on the mustache client
[03:42] <mk_> I think the node one you just chuck a json object at it
[03:43] <mk_> Ruby you chuck a hash.. etc, etc.
[03:43] <zazi> ah, okay, I think I got it now
[03:49] <mk_> btw I just updated the gist to show the external template vs embedded template
[03:49] <mk_> I think the reason I chose control for the element instead of template
[03:50] <mk_> was because otherwise the terminology got a bit confusing about what was the template and what was the form
[03:50] <zazi> hm
[03:50] <mk_> but I didn't want to use "form" so I picked control
[03:50] <zazi> well it's a template-control ;)
[03:50] <mk_> right
[03:50] <mk_> :)
[03:51] <mk_> I like control though because it's about giving the server the control of the client
[03:51] <mk_> or at least some control, anyway
[03:52] <zazi> okay, np
[03:53] <zazi> on the other side it's same like with, e.g., the 'img' tag, or?
[04:12] <mk_> how do you mean ?
[04:53] <zazi> 'img' is also like a image-control and the real image is referred via its URI
[04:58] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) joined #rest.
[05:05] hdave1 (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) left #rest.
[05:06] hdave1 (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) joined #rest.
[05:34] <darrelmiller> mk_: Did you have something to do with the internet now dropping 25% of all packets sent?
[05:34] <mk_> darrelmiller: haha, maybe ¬_¬
[05:34] <mk_> I think it might just be because the guys who produce that graph done goofed
[05:34] <mk_> rather than the whole internet
[05:34] <darrelmiller> I hope so!!!
[05:34] <mk_> yeah
[05:35] <mk_> otherwise it's tin-foil-hat time
[05:35] <darrelmiller> I noticed their last newsworth event was in 2003
[05:36] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) left irc: Read error: Connection reset by peer
[05:44] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) joined #rest.
[06:11] bigbluehat (~bigblueha@adsl-74-177-127-3.gsp.bellsouth.net) joined #rest.
[06:24] Wombert (~Wombert@xdsl-84-44-253-150.netcologne.de) joined #rest.
[06:24] <Wombert> mamund: what was the url of that blog article where someone (rightfully so) argued that a RESTful interface should never expose the domain layer?
[06:25] <darrelmiller> That's Rickard Oberg. Hold on.
[06:25] <darrelmiller> here http://java.dzone.com/articles/domain-model-rest-anti-pattern
[06:26] <trygvis> his stuff is usually quite crazy
[06:26] <darrelmiller> really? The few conversations I had with him on the CQRS/DDD lists were pretty sane.
[06:28] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[06:29] <trygvis> I haven't followed what he's been up to the last years, but the Qi4j is just crazy. also all the AOP stuff he made before that
[06:29] <trygvis> (sometimes crazy is good though)
[06:29] <darrelmiller> :-) I keep hoping so.
[06:36] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Quit: Leaving.
[06:51] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[06:52] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Client Quit
[07:15] <Wombert> that was not the article I meant, darrelmiller :)
[07:16] <darrelmiller> Huh. Ok. I can't think of another...
[07:16] <Wombert> (but thanks :D)
[07:16] <Wombert> :<
[07:17] <darrelmiller> I seem to recall the conversation coming up again recently. Can't remember who was involved though.
[07:25] <mk_> not me
[07:25] <mk_> for once
[07:26] <mk_> which significantly increases the chance of it having gone somewhere.
[07:30] <darrelmiller> mk_: Self-deprecation does not become you.
[07:30] <mk_> I know I was being sarcastic anyway
[07:30] <darrelmiller> LOL
[07:31] <mk_> ;)
[07:31] <darrelmiller> All is right with the world.
[07:37] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[07:42] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Quit: quest88
[07:55] <mk_> damn straight!
[08:14] NOKAH (~hakon1@130.82-134-26.bkkb.no) joined #rest.
[08:16] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[08:17] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[08:17] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) left irc: Ping timeout: 252 seconds
[08:18] NOKAH (~hakon1@130.82-134-26.bkkb.no) left irc: Read error: Operation timed out
[08:22] pezra (~Adium@webmail.openlogic.com) joined #rest.
[08:29] Wombert (~Wombert@xdsl-84-44-253-150.netcologne.de) left irc: Quit: Wombert
[08:36] Wombert (~Wombert@xdsl-84-44-253-150.netcologne.de) joined #rest.
[09:00] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[09:04] <hdave1> given any media type, should a person be able to ascertain what link relations it could possible have?
[09:04] <hdave1> for the most part?
[09:07] Wombert (~Wombert@xdsl-84-44-253-150.netcologne.de) left irc: Quit: Wombert
[09:13] zazi (~zazi@p579D3D60.dip.t-dialin.net) left irc: Ping timeout: 245 seconds
[09:13] <mk_> differing opinions on that
[09:13] <mk_> personally I make clients rely on their context in a 'journey' or 'flow' in the application they are traversing
[09:14] <mk_> i.e. they enter the application at an entry point (where they know the initial link relations to get started) and from then on they are following a series of link relations in a particular order
[09:16] <mk_> which is what I understand from this Roy fielding quote:
[09:16] <mk_> "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations"
[09:17] <mk_> i.e. link relations are how I expose the 'server-provided choices'
[09:17] <fu-manchu> I think hdave1 might mean "link relation *types* it could possibly have"
[09:18] <hdave1> fu-manchu: you are right...have not had any coffee today yet
[09:18] <mk_> you mean link rel values ?
[09:18] <hdave1> mk_: no -- the types of link relations (previous, next, edit, purchase, etc.)
[09:19] <mk_> yeah exactly, then I answered the question you asked :)
[09:19] <hdave1> mk_: a machine client needs to have some shared understanding with the server....I was hoping that the concept of a "media type" included all of the possible link relation types you could get back from a server
[09:20] <mk_> hdave1: why do you need to embed these in a media type ?
[09:20] <mk_> why not keep them separated ?
[09:20] <hdave1> mk_: not embed per se, just "know"....
[09:20] <hdave1> i can appreciate that you have clients rely on context in a "journey"
[09:21] <hdave1> but how can a machine client go on the journey without an understanding of what the link relation types mean
[09:21] <mk_> oh, that's documentation
[09:21] <hdave1> right
[09:21] <hdave1> documentation
[09:21] <mk_> you're talking about a m2m scenario right ?
[09:21] <hdave1> yes
[09:21] <mk_> yeah then documentation
[09:22] <hdave1> for the authors of the machine client so they can know what to expect from a server
[09:22] <mk_> at a given point in their journey (application state)
[09:22] <hdave1> yes
[09:22] <hdave1> or at any/all points
[09:22] <hdave1> i guess my question is this...
[09:23] <hdave1> without referring to a specific server, is there documentation for each IANA media type that will tell me what possible link rel I could get back from any server that uses it?
[09:23] bigbluehat (~bigblueha@adsl-74-177-127-3.gsp.bellsouth.net) left irc: Quit: Leaving.
[09:23] <hdave1> I see the IANA list of link relation types and there seems to be little correlation with media types (and vice versa)
[09:24] <mk_> IANA link relation types tend to be very generic
[09:24] <hdave1> yeah
[09:24] <hdave1> i did find this however: http://www.w3schools.com/tags/att_link_rel.asp
[09:24] <hdave1> it documents the universe of possible link relations for text/html
[09:25] <hdave1> mk_: i would have thought there would be IANA documentation for that
[09:25] <hdave1> being totally new to REST :-)
[09:27] <mk_> no idea, not 100% what you are looking for
[09:28] <whartung> o/
[09:28] KevBurnsJr (~KevBurnsW@50.0.103.39) joined #rest.
[09:29] <hdave1> just trying to understand if there is a format relationship (if any) between media types and the link relation types that can come along with them
[09:29] <hdave1> s/format/formal
[09:34] <mk_> well yeah sure some media types specify what certain rel values mean
[09:35] <mk_> AtomPub does this, so does the HTML spec afaik
[09:36] <mk_> but there aren't any applications (yet) defined purely in terms of link relations
[09:36] <mk_> wait that last statement has nothing to do with what you asked
[09:37] <mk_> oh well.
[09:38] <mk_> imo splitting the media type and the link relations apart for your app is a Good Idea(tm)
[09:43] bigbluehat (~bigblueha@adsl-74-177-127-3.gsp.bellsouth.net) joined #rest.
[09:44] <hdave1> k - thx
[09:45] <mk_> well don't thank me I could be full of crap :)
[09:56] <whartung> could be?
[10:13] zazi (~zazi@p579D3D60.dip.t-dialin.net) joined #rest.
[10:24] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving...
[10:25] caaakeeey (~caaakeeey@gatekeeper-ext.zeus.com) left irc: Quit: Leaving
[10:55] <darrelmiller> bwhahahah
[11:35] zazi (~zazi@p579D3D60.dip.t-dialin.net) left irc: Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?
[11:45] wav1 (~Adium@cpe-70-112-49-11.austin.res.rr.com) joined #rest.
[11:56] SvenDowideit (~SvenDowid@foswiki/developer/SvenDowideit) left irc: Excess Flood
[11:57] SvenDowideit (~SvenDowid@203-206-171-38.perm.iinet.net.au) joined #rest.
[11:58] SvenDowideit (~SvenDowid@203-206-171-38.perm.iinet.net.au) left irc: Changing host
[11:58] SvenDowideit (~SvenDowid@foswiki/developer/SvenDowideit) joined #rest.
[11:58] SvenDowideit (~SvenDowid@foswiki/developer/SvenDowideit) left irc: Excess Flood
[11:59] SvenDowideit (~SvenDowid@203-206-171-38.perm.iinet.net.au) joined #rest.
[11:59] SvenDowideit (~SvenDowid@203-206-171-38.perm.iinet.net.au) left irc: Changing host
[11:59] SvenDowideit (~SvenDowid@foswiki/developer/SvenDowideit) joined #rest.
[13:04] saml (~sam@adfb12c6.cst.lightpath.net) joined #rest.
[13:04] <saml> for hyper links, <a href="...">Watch Videos</a> or <a href="...">Videos</a>
[13:25] hdave1 (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) left #rest.
[13:59] bigbluehat (~bigblueha@adsl-74-177-127-3.gsp.bellsouth.net) left irc: Quit: Leaving.
[14:04] wav1 (~Adium@cpe-70-112-49-11.austin.res.rr.com) left irc: Quit: Leaving.
[14:08] saml (~sam@adfb12c6.cst.lightpath.net) left irc: Quit: Leaving
[14:16] <fu-manchu> let's say I have a document with the concept of modules inside it. I want to have document A link to a module in document B, such that a client could dereference that link and replace the link in doc A with the module at doc B
[14:16] <fu-manchu> {"element": "link", "href": "foo.json", "type": "thing"} versus {"element": "thing", "src": "foo.json"}
[14:16] <fu-manchu> which would you choose?
[14:17] <fu-manchu> is the reference in doc A of type "link" or of type "module" or "thing" or whatever the type of the referent?
[14:21] <darrelmiller> I would be tempted to treat it as a link.
[14:21] <darrelmiller> The media type spec would tell the client, oh BTW you can dereference my links and embed the result.
[14:22] <fu-manchu> sure, it can do that either way I think
[14:22] <darrelmiller> Right but you don't need a new concept if you stick with link.
[14:22] <fu-manchu> oh BTW if it has a "src" attribute, you can deref and embed
[14:23] <darrelmiller> yeah I suppose so.
[14:23] <darrelmiller> Do you really need the type=thing in the link ?
[14:23] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[14:23] <fu-manchu> well that's part of the question; I think that would make it easier for parsers and validators to assert that the replacement is of the right type
[14:24] <fu-manchu> you don't have to deref quite so much then up front
[14:25] <fu-manchu> hm, now that I think about it, it's not much different than <img src='http...'>
[14:25] <darrelmiller> I never liked HTML's seemingly abitrary use of src or href.
[14:25] <fu-manchu> versus <link src='http...' rel='foo'>
[14:25] <fu-manchu> yeah, it's certainly not very consistent
[14:26] <darrelmiller> If they had used href for LO and src for LE then that would have been cool :-)
[14:26] <fu-manchu> :)
[14:27] <darrelmiller> Not sure why the client would be responsible for determining if the response is the right type. The server provided the URI, it is responsible for what comes back , no?
[14:28] <fu-manchu> right, but take <img> for example in HTML; HTML 5 has a long section on exactly what to do even if you can't deref the URI for some reason
[14:28] <fu-manchu> that's different than what to do if you can't deref a script URI
[14:28] <fu-manchu> so it seems useful to let the client know the expected DOM type
[14:28] <darrelmiller> That's because HTML5 is actually a user-agent implementation spec, not a media type spec :-/
[14:29] <fu-manchu> haha yeah
[14:29] <fu-manchu> I'm not a fan of that aspect either
[14:29] <darrelmiller> but I digress, and we don't want to go there.
[14:29] <fu-manchu> it is nice that <img> doesn't let you embed arbitrary HTML, for example
[14:30] <darrelmiller> hmmmm....
[14:30] <fu-manchu> so in angle-bracket-land, my question would be <module src='foo'> versus <link href='foo'>, maybe <link href='foo' type='module?
[14:31] <fu-manchu> >
[14:31] <darrelmiller> but you don't have to put <img type="image/jpeg|image/gif|image|svg" src="..." /> either
[14:31] <fu-manchu> <link href='foo' type='module' action='embed'> ;)
[14:31] <fu-manchu> no, not worried about the media type, just the DOM type
[14:32] <darrelmiller> DOM type..... That's an interesting concept.
[14:33] <fu-manchu> my one media type has a dozen or so object types
[14:33] <darrelmiller> I've never thought of a media type having it's own mini type system. But I guess that's exactly what it is.
[14:33] <fu-manchu> this one actually has two! DOM objects and data types within an execution model
[14:33] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) left irc: Remote host closed the connection
[14:34] <darrelmiller> when I see <link .... /> I instantly know what that does. When I see <module ... > I don't know.
[14:35] <fu-manchu> well I have complete <module> objects in the DOM already regardless; so the question is more about seeing <module src='foo' ...>
[14:35] <darrelmiller> It's really 6 of one and half a dozen of the other, but that's just my gut feel.
[14:35] <fu-manchu> ok
[14:35] <fu-manchu> thanks for listening :)
[14:35] Wombert (~Wombert@xdsl-87-78-128-249.netcologne.de) joined #rest.
[14:36] <darrelmiller> Yeah, I can see the advantages of that approach too.
[14:39] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving...
[14:42] Wombert_ (~Wombert@xdsl-87-78-171-34.netcologne.de) joined #rest.
[14:44] Wombert (~Wombert@xdsl-87-78-128-249.netcologne.de) left irc: Ping timeout: 252 seconds
[14:44] Wombert_ -> Wombert
[15:15] pezra (~Adium@webmail.openlogic.com) left irc: Quit: Leaving.
[15:41] scudfro (~scudco@cpe-75-85-13-152.socal.res.rr.com) joined #rest.
[15:43] Split- (~split@84.34.147.60) joined #rest.
[15:48] Split (~split@84.34.147.60) got netsplit.
[15:48] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) got netsplit.
[15:48] Split- -> Split
[15:48] Possible future nick collision: Split
[15:59] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) got lost in the net-split.
[16:37] scudfro (~scudco@cpe-75-85-13-152.socal.res.rr.com) left irc: Quit: WeeChat 0.3.5
[16:41] scudco (~scudco@cpe-75-85-13-152.socal.res.rr.com) joined #rest.
[18:05] KevBurnsJr (~KevBurnsW@50.0.103.39) left irc:
[18:39] Wombert (~Wombert@xdsl-87-78-171-34.netcologne.de) left irc: Quit: Wombert
[19:13] darrelmiller (~darrelmil@70.24.176.12) left #rest.
[20:53] Wombert (~Wombert@xdsl-87-78-171-34.netcologne.de) joined #rest.
[22:09] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[00:00] --- Sat Jan 14 2012