#rest on irc.freenode.net 2010-05-05 (txt)

[00:11] mamund has frittered away enough time here. ta!
[00:13] <darrelmiller> Later Mike.
[00:47] KevBurnsJr (~kevburnsj@c-67-161-65-81.hsd1.ca.comcast.net) left irc:
[02:48] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest.
[02:49] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) left irc: Client Quit
[03:44] <jsled> .title http://statuscodedrinkinggame.com/
[03:44] <phenny> Can't connect to http://statuscodedrinkinggame.com/
[06:29] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[06:59] ordnungswidrig1 (~Adium@p5B1745B1.dip.t-dialin.net) joined #rest.
[07:02] ordnungswidrig (~Adium@p5B173E4E.dip.t-dialin.net) left irc: Ping timeout: 276 seconds
[07:04] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing
[07:16] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[07:34] KarlHungus (ssanders@for.my.n1gs.net) left irc: Ping timeout: 260 seconds
[07:37] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing
[07:38] ordnungswidrig1 -> ordnungswidrig
[07:42] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) joined #rest.
[07:54] KarlHungus (ssanders@for.my.n1gs.net) joined #rest.
[07:56] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[07:57] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Client Quit
[08:14] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[08:19] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing
[08:23] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[08:46] ramsey (~ramsey@unaffiliated/ramsey) got netsplit.
[08:47] ramsey (~ramsey@unaffiliated/ramsey) returned to #rest.
[09:33] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing
[09:43] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[09:44] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Client Quit
[09:45] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[11:43] <mikekelly> lol I keep giving this girl from one of the cloud vendors a hard time on her blog
[11:43] <mikekelly> they do 'Load Balancing' for elastic cloud/web apps
[11:44] <mikekelly> talking about how difficult it is to 'scale in' because of sessions..
[11:44] <mikekelly> /facepalm
[11:53] <algermissen> LOL
[11:55] <algermissen> I love those facepalm images that also slightly express shame for mankind
[11:57] <mikekelly> http://i357.photobucket.com/albums/oo18/redsyndicate/ImpliedFacepalm.png
[11:58] <algermissen> yeah - great
[11:58] <algermissen> amazing how often a day you feel like that
[12:00] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing
[12:07] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest.
[12:15] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) joined #rest.
[12:17] <KevBurnsJr> mamund: uri template parser is coming along
[12:17] <KevBurnsJr> http://github.com/KevBurnsJr/php-uri-template-parser
[12:18] <KevBurnsJr> http://php-uri-template-parser.hackyhack.net/tests.php
[12:18] <KevBurnsJr> There
[12:18] <KevBurnsJr> 's little in the spec about template matching
[12:18] <KevBurnsJr> mostly it's : vars + tpl = uri
[12:18] <KevBurnsJr> but I want to reverse map
[12:19] <KevBurnsJr> tpl + uri = vars
[12:19] <KevBurnsJr> that's my secret reason for writing it :P
[12:20] <KevBurnsJr> 5am. staring to hallucinate. Time for bed. Just wanted to put in progress.
[12:20] <KevBurnsJr> peace
[12:20] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) left irc: Quit: hearing sounds that aren't there.
[12:24] <darrelmiller> algermissen: Nice article on using DNS for service discovery at InfoQ.
[12:26] <darrelmiller> algermissen: It is strange that you are getting so much pushback on it though. Isn't that pretty much what an MX record is all about. Find me the SMTP server for this domain.
[12:27] <darrelmiller> algermissen: To claim that all service discovery is pointless because UDDI failed seems like throwing the baby out with the bath water.
[12:48] bigbluehat (~byoung@adsl-71-189-114.gsp.bellsouth.net) joined #rest.
[13:03] <algermissen> darrel: thanks
[13:04] <algermissen> surprised by the pushbak, too
[13:04] <algermissen> after all, it was just a summary of what one could do - nothing to fear actually
[13:04] <algermissen> when I started, I was surprised that all the was already in place with dns-sd so it felt really handy
[13:06] <algermissen> re: like MX rec - there is the additional indirection. It is more like: find me all MX servers for this domain and then second query for
[13:06] <algermissen> find me the meta data for this or that instance
[13:07] <algermissen> OTH, it is always good to be reluctant to adding stuff to an architecture :-)
[13:07] <algermissen> But I found it more straight forward than using a new media type + a well known URI
[13:09] <bigbluehat> ramsey: do you (or anyone else here) know of a good PHP-based AtomPub library?
[13:13] <darrelmiller> algermissen: Yes I think it is definitely a better approach than new registry service at a well known URL. By doing that you are just adding another layer of indirection to the coupling.
[13:17] <darrelmiller> algermissen: I use DNS for discovery but have a much easier scenario. I know there is only going to be one instance of my service within a single network so I hard code an URL such as http://tmserver:8700 in my client. I then use DNS to point to the server. This way the URL can be the same at all of my customers. (Assuming no-one else is using my port :-) )
[13:30] <algermissen> darrel: you might want to look at SRV records only. They come with port info directly so if you never have several services of a type on a single host/port then you are fine
[13:31] <algermissen> I had an interesting other issue the other day:
[13:31] <algermissen> The role that a server plays in an application really only exists once the application exists.
[13:31] <algermissen> IOW, there can not really be a service type before you have an application
[13:32] <algermissen> thinking this through leads to the 'type of service' being more like 'type of application'
[13:32] <algermissen> the DNS queryt would mean sth like: find me all instances of a search application entry URI in this domain
[13:32] <algermissen> and not: find me all search services
[13:33] <darrelmiller> "Service" is such a loaded and overloaded term.
[13:34] <algermissen> HA! yes. Service is an OO-term. In REST there is no idea of 'service'
[13:35] <darrelmiller> I feel the same way about the term REST API. It just doesn't make sense to look at a RESTful system from just the server side.
[13:36] <mikekelly> service is a contractual term
[13:37] <mikekelly> it's actually quite an important term too
[13:37] <mikekelly> :P
[13:38] <ramsey> bigbluehat: I'm (very slowly) writing one. :-)
[13:38] <darrelmiller> As I said, it is an overloaded term. ;-)
[13:38] <ramsey> bigbluehat: Other than that, no, I don't know of one.
[13:39] <ramsey> darrelmiller: I agree. REST is something that comprises the entire network, not just the server.
[13:44] <mikekelly> right - it's about building systems
[13:44] <darrelmiller> ramsey: I think that is one of the bigger conceptual leaps that people need to make when trying grok REST.
[13:44] <mikekelly> it doesn't just effect what 'service' means it also has a massive effect on what integration actually entails
[13:45] <darrelmiller> People are so used to visualizing distributed systems being seperated by these API style de-coupling points, that we try and use the same mental model when talking about REST systems.
[13:45] <ordnungswidrig> Hi guys
[13:46] <algermissen> yepp - this is where I am mentally right now
[13:46] <algermissen> integration is not system A talking to system B
[13:47] <algermissen> but user X engaging in an application Y
[13:47] <algermissen> X just interacts with the app on the basis of steady states
[13:47] <algermissen> and the means to do this is a user agent
[13:47] <algermissen> trying to map that to business processes
[13:48] <algermissen> .... is every action of a process user an execution of a network application?
[13:48] <algermissen> or is the whole process a multi-user networked appication?
[13:53] <bigbluehat> ramsey: is that the Lithium based one?
[13:53] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest.
[13:56] <ramsey> bigbluehat: there are several incarnations. One was going to be just straight PHP designed after Abdera. Another was going to be a PECL extension designed after Abdera, and the third was Lithium-based, but I didn't get very far with it.
[13:56] <ramsey> bigbluehat: I'll need to revisit it soon for work, actually.
[13:56] <ramsey> bigbluehat: So, maybe I'll get some traction and actually finish one of those. :-)
[13:57] <ramsey> bigbluehat: I'll probably go with writing the extension, but I'll write it very lightweight and for PHP 5.3, hopefully making it easily interoperable with Lithium, Symfony 2, Zend Framework 2, etc.
[13:58] <ramsey> bigbluehat: I should draw up some ideas/plans, blow away my old github repos and get started on a new one that I open up for others to work on :-)
[13:59] <bigbluehat> ramsey: I'd be happy to help
[14:00] <bigbluehat> ramsey: not sure what I could contribute in way of a pecl extension, but would be happy to test it
[14:00] <bigbluehat> ramsey: have you looked at pecl_http much? seems great, and could be the basis (or useful) in building an atom extension or even standalone PHP app
[14:01] <ramsey> bigbluehat: Yeah, I've considered that as a basis or a dependency.
[14:01] <bigbluehat> ramsey: I'd love to see that in more people's toolbelts
[14:01] mamund has arrived, let the party begin!
[14:01] <bigbluehat> seems like a great extension
[14:01] <ramsey> bigbluehat: Another option is to design/write it first in PHP using pecl_http and XMLReader/XMLWriter and then translate it into a PECL extension later.
[14:01] <bigbluehat> ramsey: I could help with that. :)
[14:02] <ramsey> bigbluehat: but, yeah, I definitely need help on it :-)
[14:02] <bigbluehat> ramsey: I'm wanting full AtomPub support in our BlueInk CMS, so I'd be happy to contribute
[14:02] <ramsey> bigbluehat: okay... I'll "restart" my repo later this week. If I haven't done anything by Friday, pester me about it. :-)
[14:02] <ramsey> bigbluehat: can you use 5.3 with that CMS?
[14:03] <bigbluehat> ramsey: BlueInk runs fine on PHP 5.3, but as yet doesn't *require* it
[14:03] <bigbluehat> though, I'm fine if that's in its near future
[14:03] <ramsey> Right. I mean, is it okay for this to require 5.3?
[14:03] <ramsey> i.e. namespaces, closures, etc. are features I want to use in order for this to work best with the next generation of PHP frameworks
[14:04] <bigbluehat> ramsey: I think so. we'll be upgrading our servers within the year, and I hope to encourage the others hosting BlueInk (as intranet apps) to move up to PHP 5.3 & install CouchDB :D
[14:04] <ramsey> cool
[14:04] <bigbluehat> ramsey: completely understand
[14:04] <bigbluehat> ramsey: I've already convinced the intranet folks to put pecl_http in place, so hopefully Couch & PHP 5.3 won't be too hard ;)
[14:04] <ramsey> hehe
[14:04] <bigbluehat> I'm meeting with them today at 12, so I'll let them know what's coming. ;)
[14:05] <ramsey> We're upgrading production to 5.3.2 in about 2 weeks
[14:05] <bigbluehat> ramsey: for moontoast?
[14:06] <ramsey> yes
[14:09] <bigbluehat> ramsey: is XML(Reader|Writer) prefered to the other XML options PHP has? if so, why? (curious)
[14:09] <ramsey> bigbluehat: by chance, will you be at tekx?
[14:09] <ramsey> Preferred for speed. It's a SAX-based parser, rather than DOM.
[14:09] <ramsey> It's on by default in all 5.x installations, too.
[14:10] <bigbluehat> ramsey: sadly, no. My wife's getting her MFA in play writing and will be at her residency in Kentucky that week (or just after), so can't make it
[14:10] <ramsey> Ah, sorry to hear for you, but good for her! :-)
[14:10] <bigbluehat> indeed :)
[14:12] <mamund> KevBurnsJr: your uri-template implementation is looking good so far. (hopefully you're getting some sleep now<g>)
[14:12] <bigbluehat> mamund: where's that at?
[14:13] <bigbluehat> ramsey: have you played with phpQuery at all?
[14:13] <bigbluehat> uses the DOM in PHP, but it's a farily complete port of jQuery's API to PHP
[14:15] <ramsey> bigbluehat: nope... never heard of it
[14:15] <ramsey> Why would you want to port jQuery's API to PHP?
[14:16] <mamund> bigbluehat: KevBurnsJr included links in the channel here early today. check here: http://rest.hackyhack.net/2010-05-05.html#41/h41
[14:17] <mamund> algermissen: interesting article. FWIW, don't let the doubters sway your thinking.
[14:17] <bigbluehat> ramsey: server-side DOM parsing for templates and such, or screenscarping
[14:17] <bigbluehat> ramsey: you then have pure HTML fragments that can be used elsewhere with various phpQuery parsing to have them contain different content, etc (think CMS ;) )
[14:18] <algermissen> mamund: nah - never :-)
[14:18] <bigbluehat> mamun: thanks. taking a look
[14:20] <bigbluehat> KevBurnsJr: what are your thoughts on Recess (the PHP framework)
[14:21] <mamund> algermissen: as an early UDDI adopter and promoter (/me hangs his head), i can see your solution is _nothing_ like UDDI and is much more open, flexible, and usable.
[14:22] <mamund> also, IMO, the whole "service discovery" meme trips switches in some folks' heads and generates instant reactions w/o thinking through the details.
[14:22] <mamund> i see this happen if someone uses the word "transaction" in the same sentence as "REST", too.
[14:23] <algermissen> true
[14:24] <mamund> anyway, good idea; well-written article, too.
[14:25] <algermissen> hey, thanks! Already planning a follow up :-)
[14:25] <algermissen> But it takes time to write such things (me at least)
[14:26] <algermissen> when I wrote the article, I still thought in terms of services...
[14:26] <algermissen> now I think in terms of applications
[14:27] <algermissen> so the title should be more like "Using DNS for networked application entry URI discovery"
[14:27] <algermissen> ... which makes me scratch my head :-)
[14:28] <algermissen> Service are not really aware of the nature of the applications they participate in ...
[14:28] <mamund> algermissen: you know, i was thinking about this as i read your article...
[14:29] <mamund> when you apply DNS to RESTful apps, you really see that (someone said is earlier here today) programming in REST is programming _the_entire_network_
[14:29] <mamund> and, when programming the network, DNS is a vital component, IMO.
[14:30] <mamund> i think DNS is one of the most successful of the app-level network protocols...
[14:30] <mamund> and it's not leveraged enough. your article shows just one way to re-think that protocol, IMO.
[14:30] <algermissen> ah - "Rethinking DNS" what a slick title :-)
[14:31] <algermissen> Let me try another wording....
[14:31] <algermissen> Looking at the title "Search Engines" of my bookmark folder for search engines..
[14:31] <algermissen> what does "Search Engines" identify?
[14:31] <algermissen> A kind of REST application?
[14:32] <algermissen> Certainly *not* a service type
[14:33] <algermissen> Because it is not me that uses the server - the user *agent* uses the server. I just use the application.
[14:33] <algermissen> So what I look for is entry URIs for apps, not service URIs
[14:33] <mamund> yes, interesting line of thinking.
[14:34] <mamund> "search" is an app, then.
[14:34] <algermissen> Yep
[14:34] <mamund> i've been thinking along the lines that every "app" i add to the network is just a "component" or some other phrase
[14:34] <mamund> "the app is the net" maybe
[14:35] <algermissen> hmm - question: what does it mean to 'add an app'?
[14:35] <mamund> it's easy to see that adding my HTML page is just one more "page" on the web.
[14:35] <mamund> if i add an "app", what am i adding?
[14:35] <algermissen> step back..
[14:35] <mamund> well, i program the network (that's my app)
[14:35] <mamund> k
[14:35] <algermissen> app vs app execution instance
[14:35] <mamund> uhhh
[14:36] <mamund> not following
[14:36] <algermissen> does an app exist in the absence of its own execution?
[14:36] <algermissen> shivering
[14:37] <mamund> ok, no.
[14:37] <algermissen> ah - to me: yes
[14:37] <algermissen> Example:
[14:37] <mamund> ok
[14:38] <algermissen> Apps are implemented by user agents
[14:38] <darrelmiller> algermissen: I think it is more valuable to consider each interaction "01an execution of a network application". It keeps you focused on stateless interactions.
[14:38] <algermissen> Browsers implement one app - downloading a web page?
[14:38] <algermissen> s/?/"/
[14:39] <algermissen> when a user enters a URI in the browser it startes the app
[14:39] <algermissen> the user agent executes the app towards the next steady state
[14:39] <algermissen> which is the Web page
[14:39] <algermissen> the human interpretation on top is
[14:39] <algermissen> misleading because we think it is part of the app - but it is not
[14:40] <algermissen> yech - that is confusing
[14:40] <algermissen> because I am still working on it myself
[14:40] <algermissen> ]
[14:41] <algermissen> Very hard to get the human mind out of the way
[14:41] <algermissen> because we are so biased by it since it is he only REST use there is
[14:41] <algermissen> (even AtomPub is eventually human targetted)
[14:42] <algermissen> Hmm - need to sort my brain I guess.
[14:43] <algermissen> There seems to be something in the direction of building blocks for apps and apps
[14:43] <algermissen> user uses the building blocks (the steady states if you want)
[14:44] <algermissen> and creates the actually application instance while steping through it
[14:44] <algermissen> but inside the user agent -to- server(s) automatic progress there are the 'building blocks' moving
[14:45] <algermissen> bah - will stop. This leads nowhere right now (sorry)
[14:45] <mamund> general comment: the "app vs. app instance" strikes me as a tautology that applies to all things. e.g. "the map is not the territory"
[14:46] <mamund> IOW, i don't find it helpful to point this out most of the time.
[14:46] <algermissen> consider this:
[14:46] <algermissen> buying a book on the Web is an app
[14:46] <algermissen> where is that app realized?
[14:47] <algermissen> in your brain? In your browser?
[14:47] <algermissen> in the steady states?
[14:47] <mamund> heheh....
[14:47] <algermissen> do you start the app? or is it just there all the time?
[14:48] <mamund> being more blunt: why is this difference (app vs. app instance) important?
[14:48] <algermissen> dunno :-)
[14:48] <mamund> aha!
[14:48] <mamund> pushing the metaphysical implications of the question...
[14:49] <algermissen> I am just a bot consuming your time with philosophical distractions :-)
[14:49] <mamund> all of your life is a mere representation of reality. where is the app now, grasshopper?
[14:49] <mamund> <g>
[14:49] <algermissen> I am the app - and time is it's execution
[14:50] <algermissen> Its likely more a matter of model and reality, not of type/instance
[14:50] <algermissen> consider a buying a book use case
[14:50] <algermissen> at the modeling level
[14:50] <algermissen> how and where is it realized?
[14:51] <algermissen> IMO: by combination of user intent and user agent implementation
[14:51] <algermissen> and if there is no user intent: only by the user agent (see MOMspider for example)
[14:52] <algermissen> 'checking site for dangling links' is the use case realized by Roy's MOMspider
[14:52] <algermissen> no user involvement (except starting it)
[15:03] <ordnungswidrig> Hmm, any thought about URN vs. URI vs. URL? I have business model, say products, product catalog, order etc. When I post a order-representation to a order-inbox-resource shall the product be referenced by a URL or by a URN?
[15:03] <ordnungswidrig> what's the pro's and con's?
[15:06] <mamund> ordnungswidrig: is this for internal storage or external representations?
[15:07] <ordnungswidrig> mamund: good point. internal I don't really care because I'll have to do some mapping to a db-key anyway.
[15:07] <ordnungswidrig> mamund: I care more about moving servers and changing urls
[15:07] <mamund> ok
[15:08] <ordnungswidrig> mamund: that a representation of product no. 2203 is available at http://text/products/2203 is accidental.
[15:08] <mamund> well, temporal at least, right?
[15:09] <ordnungswidrig> mamund: right, I can translate to a internal id at request time.
[15:09] <mamund> this doc might help you decide: http://www.w3.org/TR/uri-clarification/
[15:09] <ordnungswidrig> I wonder if I get benefits in using urns or urls-as-uri to identify products. This would work in a REST-over-STMP scenario as well
[15:10] <ordnungswidrig> I read the paper but I came to the conclusion that there is no private URN scheme, right?
[15:11] <mamund> private?
[15:11] <ordnungswidrig> unregsitered, like private mime types: text/vnd.com.mydomain+xml
[15:12] <ordnungswidrig> mamund: I know that I can use a http URL as a URI like xml schema does but this encourages people to try to "access " the URL
[15:12] <mamund> you can create URN details the same way you do URI details
[15:12] <mamund> ohhh....
[15:12] <mamund> you mean minting URIs that can't be dereferenced, then?
[15:14] <ordnungswidrig> mamund: yes. or that can be dereferenced by the server only (which it must be able to).
[15:15] <mamund> well, not sure about that last comment about who can deref the URI but...
[15:16] <mamund> i use URNs within representations for things that i want to be unique, but don't want the client to attempt to de-ref.
[15:16] <mamund> i treat the URN scheme as my "internal map" moniker in representations (if that makes sense)
[15:16] <ordnungswidrig> mamund: like xml processing applications that have a resolver that can resolve the ns uri for certain schemata to a locally stored copy of the schema declaration
[15:16] <ordnungswidrig> ok, so a URI that is not a URL might by the way to go then?
[15:18] <mamund> yeah, as in URN.
[15:18] <ordnungswidrig> so why not an URN
[15:19] <mamund> a URN _is_ a URI that is not a URL<g>
[15:21] <mamund> sorry, ordnungswidrig, maybe i've lost the plot here and confused both of us.
[15:21] <mamund> in my head, URL is a de-reference-able item, URN is not. both are URIs. it's how i have them arranged in my head. (maybe that's not correct?)
[15:25] bigbluehat (~byoung@adsl-71-189-114.gsp.bellsouth.net) left irc: Quit: bigbluehat
[15:25] <ordnungswidrig> sorry, it was me that was confused by URN<->URL
[15:26] <ordnungswidrig> but you can _resolve_ a URN to a URL, right?
[15:27] <mamund> ok, i understand.
[15:28] <mamund> if you're using the URN scheme, i don't know of any clients that resolve that to a place "on the web" if that's the Q.
[15:40] <ordnungswidrig> ok, but resolving a URN is a concept that exists, right?
[15:40] <mamund> yes
[15:43] <ordnungswidrig> ok, I'll use URN to identify my business entities which I resolve to URL which accept and return representations...
[15:45] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) left irc: Quit: mhausenblas
[15:58] <mamund> ordnungswidrig: this might give you some hints on how folks were thinking about writing URN resolvers: http://tools.ietf.org/html/rfc2169
[16:00] <ordnungswidrig> mamund: oh yes, I now that. could be useful, as well as a server the can resolve URN to it's private internal representation (e.g. db key) itself
[16:01] <ordnungswidrig> s/the can/that can/
[16:03] <mamund> yep. mostly historical stuff there, was listed as experimental and is from '97.
[16:12] <ordnungswidrig> hmm, all I can found about resolving URNs is about a closed set of URNs, like in the oasis URN schema, but I guess there is nothing to say against URL templating when resolving a URN to a URL. so urn:vnd:example.test:products:{productId} -> http://erp.example.test/here/are/the/products/{productId}
[16:21] <mamund> yeah, the point is that you are in charge of documenting the custom resolver.
[16:22] <mamund> you can tell clients (agents) that they need to be able to do this...
[16:22] <mamund> or you can tell servers they need to do this.
[16:22] <mamund> if you are really serious, you can register the NID w/ IANA, too.
[16:23] <ordnungswidrig> hmm, regarding a web shop workflow: the server sends a catalog repr with urls to products, the client "stores" product url in it's cart and posts the cart-representation to the order inbox resource
[16:23] <ordnungswidrig> so URNs are internal only
[16:24] <ordnungswidrig> or the client extracts the product URN from the product resource representation and posts the URNs in a cart representation to the server.
[16:24] <ordnungswidrig> The latter would enable to post a cart to a server that was not aware of the product resource of the catalog server
[16:26] <mamund> well, even when using URLs, the server that receieves the cart need not "know" about the products. they could have come from some other server(s)
[16:27] <ordnungswidrig> so why having URNs when there are unresolvable URLs?
[16:30] <mamund> well, they need not be unresolvable to still be "unknown" to the target server, right?
[16:31] <ordnungswidrig> the target server will only be able to handle dereferncable URIs because it needs to get a price quote and title form the catalog server, e.g.
[16:32] <mamund> ahh
[16:32] <mamund> ok
[16:32] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest.
[16:32] <ordnungswidrig> so either URN -> URL or http-URL-as-URI -> URL will work.
[16:32] <mamund> yep
[16:33] <ordnungswidrig> but the latter will lead people to skip the URI resolution and try to _use_ the URI as a URL
[16:33] <mamund> again, if you use a URN you can also document a method for de-refrencing them using a custom resolver.
[16:33] <mamund> well, what people are "led" to and all is kinda outside your control.
[16:37] <ordnungswidrig> mamund: but the usage of http-URLs as URIs led to kind of ddos agains the w3c servers because of dumb xml processors which downloaded the file every time
[18:08] bigbluehat (~byoung@64.134.182.242) joined #rest.
[18:20] insanekane (~kane@116.68.73.149) joined #rest.
[18:22] <mamund> ordnungswidrig: was away for a while...
[18:23] <ordnungswidrig> me also :-)
[18:23] <ordnungswidrig> just returned
[18:29] <ordnungswidrig> mamund: time for another subject to talk about?
[18:33] <mamund> hehehe
[18:33] <mamund> sure
[18:38] <ordnungswidrig> one can have authentication at the transport level (http auth) or at the representation level. For an order processor you can secure it with http authentication or you can digitally sign the order request representation that you post. right?
[18:38] <ordnungswidrig> the latter is latter is uncomment with REST as far as I can see
[18:39] <ordnungswidrig> s/uncomment/uncommon/
[18:43] <mamund> if i understand you, neither is related to REST directly...
[18:43] <mamund> transport auth is HTTP-related (as a layer)
[18:44] <mamund> signing either bodies or URIs is "an implementation detail" and not protocol or arch-style specific
[18:44] <mamund> does that make sense?
[18:45] <ordnungswidrig> mamund: well, not related to REST is a good point. I just came to the insight that authenticating at transport level will make authentication more lightweight because you must not take the content into account.
[18:46] <ordnungswidrig> however you cannot forward the request further to another system to process the request because you cannot forward the authentication itself.
[18:47] <mamund> yeah, that's a good way to look at it...
[18:47] <ordnungswidrig> hmm, but for GET request you must authenticat at the request / protocol level...
[18:48] <mamund> i use transport auth to set the identity of the user
[18:48] <ordnungswidrig> brb
[18:48] <mamund> i use other forms of encryption to ensure the integrity of the message
[18:58] <ordnungswidrig> re
[18:58] <ordnungswidrig> other forms?
[18:59] <ordnungswidrig> at the protocol level?
[19:03] <algermissen> keep in mind that auth affects cacheability so you need to do it at the HTTP level - The Authenticate header has distint meaning to caches.
[19:04] <mamund> i use TLS to encrypt the message...
[19:04] <mamund> i use in-message encryption as a way to sign certain parts of the message
[19:06] <ordnungswidrig> algermissen: right. that is for get requests. in-message encryption is usable only for put/post
[19:06] <algermissen> sorry if I missed that that has already been said. was away
[19:07] <mamund> i sometimes use URI signing to control lifetime or other details of the link, too.
[19:07] <algermissen> mamund: ready for take two on the application issue?
[19:07] <ordnungswidrig> control lifetime?
[19:17] <mamund> ordnungswidrig: yeah, link might only be valid for a limited length of time, might only work for X number of requests, etc.
[19:17] <mamund> algermissen: go for it!
[19:18] <algermissen> application is 'created' through user's intent - the application is what the user makes of the steady states it accesses via the user agent
[19:19] <algermissen> the media types and the user agent implementation (it's interpretation and assumptions of the media types)...
[19:19] <algermissen> greatly affects the possible applications the user can actually 'execute'
[19:19] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) joined #rest.
[19:20] <algermissen> in that sense user agent implementations...
[19:20] <algermissen> prescribe the kind or family of possible applications
[19:20] <algermissen> MOMspider for example is a user agent..
[19:21] <algermissen> that implements only one application...
[19:21] bigbluehat (~byoung@64.134.182.242) left irc: Quit: bigbluehat
[19:21] <algermissen> because it never comes back with an intermediate steady state for the ..
[19:21] <algermissen> user to actually make a decision that would change the application
[19:22] <algermissen> web browsers are the other extreme for of user agents
[19:22] <algermissen> because they come back with a steady state *very* often and make possible very many applications
[19:22] <algermissen> such as buying a book or checking for availability of a book
[19:22] <algermissen> or just checking its price
[19:22] <algermissen> phew
[19:23] <algermissen> so it is not just the media types that affect what apps are possible
[19:24] <algermissen> also the user agent implementations affect that
[19:24] KevBurnsJr just missed bigbluehat
[19:25] avdi (avdi@c-174-55-88-101.hsd1.pa.comcast.net) left #rest.
[19:27] <mamund> algermissen: i certainly agree with the final point: agent implementations are key (i often think of them as the limiting factor) in the implmentation of the app
[19:29] <algermissen> and - do you at least understand what I mean in the previous points :-)?
[19:31] <mamund> algermissen: i think i understand it, but am struggling to grasp it's importance
[19:33] <algermissen> The importance is to get an understanding of the significance of the individual elements (user, UA, media type, application)..
[19:34] <mamund> i see
[19:34] <algermissen> to have a good basis for principled user agent and media type design
[19:34] <algermissen> Media type design for example essentially affects the possible steady states you *can* have
[19:35] <ordnungswidrig> Is the representation of a resource expected to be the same for put/post and get? (for the same media-type)
[19:35] <algermissen> user agent design affects the steady states you *will* have (IOW - when the control is handed back to the user)
[19:35] <algermissen> ordnungswidrig: no
[19:37] <ordnungswidrig> so I can post a order-resource-representation which identifies products by an id and will get a representation which represents them by URLs to the a product resource?
[19:38] <algermissen> server is free to do whatever it likes
[19:39] <ordnungswidrig> I know. I was thinking about what would be good for clients
[19:42] <ordnungswidrig> When a product in an order resource is represented by a URI then the server will have to parse the URI and translate it into an internal represenation, e.g. a db key.
[19:44] <algermissen> ordering is not so easy
[19:44] <algermissen> you basically need agreement about the item IDs
[19:44] <algermissen> one way is sending them in form for client to select
[19:45] <algermissen> If you have URIs for the items then telling the client about them in the order confirm is maybe good
[19:45] <algermissen> but you need to tell it the mapping, too I guess.
[19:46] <ordnungswidrig> algermissen: server offers a catalogue resource which contains the URIs of product, or they are available from a search resource.
[19:46] <algermissen> Look at UBL item identification for more sophisticated stuff :-)
[19:46] <algermissen> (I'll search link if you are interested)
[19:46] <ordnungswidrig> I looked at UBL but the use URNs, right?
[19:47] <ordnungswidrig> or better they use ids, right?
[19:47] <algermissen> No - the use buyerItemIdentification, sellerItemIdentification, standardItemIdentification and they all can be strings or strings of a scheme
[19:47] <algermissen> basically UBL uses whatever the parties agreed on to be used :-)
[19:47] <ordnungswidrig> ok, so a ui would be a special kind of string
[19:47] <ordnungswidrig> s/ui/uri/
[19:50] <algermissen> wonders why his tomcat for UBL catalog is down...
[19:51] <ordnungswidrig> using URIs to identify a product might be a good idea, a rest http server typically knows how to deconstruct URIs and mapping URL to the part of code which "implements" a resouce is the core of a http server.
[20:10] <ordnungswidrig> guys, another one. Do anybody know of a javascript lib to implement a RESTful client in the browser? Something that fetches resources, you can define how to react on a media type and so on.
[20:14] <mamund> i just use a custom ajax class i wrote and handle the details within my custom pages (accept, content-type, etag, etc.)
[20:31] <ordnungswidrig> I thought of a state machine which transitions a triggered by the responses. However that would be unrestful because the client should react to any media type it knows.
[20:35] <mamund> ordnungswidrig: i've written lots of clients that only know one media type.
[20:37] <ordnungswidrig> so the state transitions is handled how?
[20:37] <mamund> not sure of the Q
[20:44] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) left irc:
[20:47] <ordnungswidrig> hmm, I you can model the client as a state machine which reacts to the pages. Or the server is the state machine and the client's state is a simple linear list of URLs
[20:47] <ordnungswidrig> mamund: you get the idea?
[20:48] <mamund> hmmm... not really.
[20:49] <mamund> ok
[20:49] <mamund> state transitions as in "how does the client now how to follow links?"
[20:49] <mamund> if that's the Q, i do this using link relations
[20:50] <mamund> if the client has a specific goal, i can learn the possible transitions from checking on the documented link relations and programming the client accordingly
[20:51] <algermissen> let me try my latest epiphany :-)
[20:51] <algermissen> ordnungswidrig: what is your use case?
[20:51] <algermissen> as in "buying a book"
[20:51] mamund sits down and grabs a hold of his seat.
[20:51] <algermissen> yeah - hold tight!
[20:52] <algermissen> .. wonder how that works out: explaining rest from the other end
[20:52] <algermissen> member:ordnungswidrig:?
[20:53] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Remote host closed the connection
[20:53] <algermissen> why is it that people allways leave when I start to type?
[20:54] <mamund> heheheeh
[20:54] <algermissen> trying again: ordnungswidrig - what is your use case (just the title I mean)
[20:55] <algermissen> maybe ordnungswidrig did not grab a hold of his seat and is now on the floor?
[20:55] <mamund> ROFL
[20:55] <mamund> ok, try me!, try me!
[20:56] <algermissen> :-) But I want to help *him* so he should be there (or she?)
[20:56] <mamund> him
[20:56] <mamund> yeah
[20:56] <mamund> i agree
[20:57] <algermissen> waits...patiently
[20:58] <ordnungswidrig> re
[20:58] mamund stares at the cieling, quietly whistling
[20:59] <mamund> ah!
[20:59] <ordnungswidrig> sitting on my chair again
[20:59] <algermissen> ah! so here it comes again - wipe out your brain (especially clear *all* OO concepts)
[21:00] <ordnungswidrig> did not fall of, had to place the waste baskets on the street for pickup tomorrow :-)
[21:00] <ordnungswidrig> I put it in the basket
[21:00] <algermissen> what did you put in the basket?
[21:01] <algermissen> anyway: ordnungswidrig: what is the title of your use case?
[21:01] <ordnungswidrig> I put all OO concepts into a basket. Then I set the basket on fire. I'm more in FP, you know.
[21:01] <ordnungswidrig> So the title of the use case
[21:02] <ordnungswidrig> As a Customer I want to place an order in an web shop which is built as a javascript client talking to a rest over http server.
[21:03] <algermissen> So the user is a human? or a machine?
[21:03] <algermissen> s/user/primary actor/
[21:03] <ordnungswidrig> Human. At least that is the kind of user I care about.
[21:04] <algermissen> hmm - but then this is a normal human to browser use case?
[21:05] <ordnungswidrig> algermissen: yes. it's the client connector we talk about, I suppose. Not a generic browser but a javascript application which is used by the user and which talks to a server.
[21:05] <algermissen> ok, will try anyhow - it is just harder to see what I mean then, I guess.
[21:06] <algermissen> so there is actor and use case
[21:06] <algermissen> the Q is how to realize the use case
[21:07] <ordnungswidrig> yes, the actor is the customer (human) the use case is find some products and place an order.
[21:07] <algermissen> we will realize the use case as a networked application (because for some reason it has to be networked - in our case that is obvious)
[21:07] <algermissen> first, anticipate the interactions the user needs to make with the application
[21:07] <ordnungswidrig> ok
[21:08] <ordnungswidrig> request catalog, post order
[21:08] <algermissen> application needs to pause and return control to actor in order for actor to do next step - ok?
[21:09] <ordnungswidrig> ok. thats how a web browser works.
[21:09] <algermissen> (for some REST apps, no actor interactions are necessary: e.g. crawling a site)
[21:10] <algermissen> Now - how does the actor interact with the application?
[21:10] <ordnungswidrig> in my case?
[21:10] mamund everyone should check out this video on a RESTful "buying" agent: http://guilhermesilveira.wordpress.com/2010/04/13/buying-through-rest-applying-rest-to-the-enterprise/
[21:10] <ordnungswidrig> the video is nice.
[21:10] <algermissen> I sense a disturbence in the force
[21:10] <algermissen> not in your case - in any case
[21:11] <ordnungswidrig> this depends on the application I suppose
[21:11] <algermissen> no: in REST the actor interacts with the application through the user agent
[21:11] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest.
[21:11] <algermissen> (in your case that is a browser)
[21:11] <ordnungswidrig> oh I see.
[21:12] <algermissen> What the user agent does is this:
[21:12] <ordnungswidrig> so I try to build a javascript-in-the-browser user agent specialized for my shopping application?
[21:12] avdi (avdi@c-174-55-88-101.hsd1.pa.comcast.net) left #rest.
[21:12] <algermissen> - present and make accessible the application state (received as HTTP response)
[21:13] <algermissen> - turn the controls (links and forms in HTML case) into sth that allows the actor to activate the controls
[21:13] <algermissen> - construct appropriate request upon activation of a control by the ctor
[21:13] <ordnungswidrig> ...actor
[21:14] <algermissen> yes, actor
[21:14] <algermissen> the user agent will automatically follow hypermedia controls until it reaches the next steady state (in your case a Web page)
[21:15] KevBurnsJr (~kevburnsj@c-67-161-65-81.hsd1.ca.comcast.net) joined #rest.
[21:15] <algermissen> (note: when a steady state is reached is a user agent specific decision - made by the programmer of the agent (or by config))
[21:16] <algermissen> once a steady state is reached, control is turned back to the actor
[21:16] <algermissen> so the actor can choose one of the transitions by activating the hypermedia control (link or form)
[21:16] <algermissen> once that is activated, the user agent constructs the request that corresponds to the activation made by the actor
[21:17] <algermissen> .... with me so far? Let's relate that to your Q above then ...
[21:17] <ordnungswidrig> yes.
[21:17] <ordnungswidrig> wait
[21:17] <ordnungswidrig> what about state in the user agent. A shopping cart, for example
[21:17] <algermissen> good Q.
[21:18] <algermissen> not yet integrated that in my mental model
[21:18] <algermissen> guess it it part of the steady state
[21:18] <algermissen> and is exposed as a control to be activated (and changed) by user - hmm. Need to think about that.
[21:19] <ordnungswidrig> this was the exact question :-)
[21:19] <algermissen> Wait
[21:20] <algermissen> I think it is just exposed as controls for user (GUI elemnts in your case)
[21:20] <algermissen> the interesting thing is that...
[21:21] <algermissen> activation of these controls does not result directly in an HTTP request
[21:21] <algermissen> (like: add item to cart)
[21:21] <ordnungswidrig> yes, it's only about state in the agent
[21:21] <algermissen> but it affects the request that is being made later on
[21:21] <algermissen> Very interesting!
[21:22] <algermissen> re you practical problem - what is your exact Q
[21:24] <ordnungswidrig> I want to build a javascript user agent which does the shopping workflow. First the actor request a catalog (or parts of it) or searches of a product. then the user places some products into a cart (held in the user agent) and finally it posts the cart to the server as an order. Because there is no conversational state between client and server will work out. When the server receives the order representation it does not know anything about t
[21:24] <algermissen> ok wait...
[21:24] <ordnungswidrig> So the Q is: is there some architecture or design pattern or javascript lib for the client side.
[21:25] <algermissen> Hmm - are you asking, how to maintain and update the client side basket?
[21:25] <ordnungswidrig> general insights
[21:26] <ordnungswidrig> e.g. how to handle "unexpected" responses by the server.
[21:26] <ordnungswidrig> My first idea was to enable the web browser to handle custom media types and to render them as HTML.
[21:26] <algermissen> So you do not want me to say that sth like jQuery likely provides a client storae apstraction based on (RESTfully used ) Cookies?
[21:27] <ordnungswidrig> client storage is not the real problem :)
[21:27] <algermissen> you say: "unexpected responses" - responses to requests made by the user?
[21:28] <algermissen> Actually I fail to see what you "javascript user agent" would actually do?
[21:29] <algermissen> (gee - excuse my typing)
[21:29] <ordnungswidrig> yes, like this: the javascript user agent follows a cataloge link to a product resource. If the response is text/vnd.mycompony.product+xml then the user agent display it in the application at a certain place etc. But what if the server reponds with a text/vnd.mycompany.order+xml ?
[21:29] <ordnungswidrig> I'm talking about a "rich javascript think client"
[21:29] <algermissen> Ah - I thought you were talking about browser plus HTML and JS
[21:30] <algermissen> ok - start over
[21:30] <ordnungswidrig> more a JS application which runs in a browser and renders it's ui as HTML
[21:30] <algermissen> (I start over)
[21:30] <ordnungswidrig> :)
[21:31] <algermissen> does the application need the steady state of catalogue at all?
[21:31] <algermissen> or can the user tell the JS-UA...
[21:31] <algermissen> what product characteristics it is looking for in the first place?
[21:32] <algermissen> what I mean is: you only need the catalogue steady state if the actor intends to *act* upon it
[21:32] <algermissen> .. make a decision
[21:33] <algermissen> but anyhow...
[21:33] <ordnungswidrig> no, in this case, it's a convenience for the user. So it doesn't need to enter a "product no". But this is about user<->user agent, not user-agent<->server
[21:33] <algermissen> ok
[21:33] <algermissen> to your point:
[21:33] <algermissen> Your JS-UA is started by the actor
[21:34] <algermissen> then the JS-UA GETs the entry uri
[21:34] <ordnungswidrig> the ua must have a "default goal" then
[21:34] <algermissen> and receives a catalogue
[21:34] <ordnungswidrig> yes
[21:34] <algermissen> now comes the often overlooked trick:
[21:34] <ordnungswidrig> *drumroles*
[21:35] <algermissen> because the client finds the link in a catalogue it can safely assume that the link target is a product
[21:35] <ordnungswidrig> judging by the media type of the catalogue
[21:36] <algermissen> yes! much like a browser assumes that <img src="" points to an image
[21:36] <algermissen> (that is why Accept header for such image retrieval is Acept image/*
[21:36] <algermissen> not text/html,image/*,app/xml
[21:36] <algermissen> So a server can be tested for such errors
[21:37] <algermissen> and text/vnd.mycompany.order+xml would just be a broken server
[21:37] <ordnungswidrig> Ah, so the assument type of the link target will go into the accept header
[21:37] <algermissen> Hmpf - no :-)
[21:37] <algermissen> little more complicated
[21:38] <algermissen> the JS-UA assumes the 'kind' of the link target resource (a product)
[21:38] <ordnungswidrig> btw. chrome sends no accept header when requesting images.
[21:38] <algermissen> it then must somehow(we come to that later) understand which..
[21:39] <algermissen> media types it can handle for the expectation that the resource 'is a product'
[21:39] <algermissen> in your case ext/vnd.mycompony.product+xml
[21:39] <algermissen> in the browser case image/*
[21:39] <ordnungswidrig> ok
[21:40] <algermissen> The association between images and image/* media types is implicitly made in all the RFCs
[21:40] <algermissen> it is an open issue (IMHO) how such things are connected.
[21:40] <algermissen> conider Opensearch
[21:41] <ordnungswidrig> in my case it's that the links of rel "product" in text/vnd.mycompany.catalogue+xml are expected to by of type .../product+xml
[21:41] <algermissen> be careful
[21:41] <algermissen> the thing is that your JS-UA
[21:42] <algermissen> somehow associates the target of catalogue links (aka products) with
[21:42] <algermissen> its capability to interprete ../product+xml as representations of them
[21:43] <algermissen> back to Opensearch
[21:43] <ordnungswidrig> ok
[21:43] <algermissen> there the assumption is (by prose in spec) that the result of a search form
[21:43] <algermissen> is a list of hits
[21:43] <algermissen> and then the spec states that such formats as Atom feeds or RSS can be used for those
[21:44] <algermissen> so OpenSearch UAs would Accept: app/atom;type=feed, app/rss or so
[21:44] <algermissen> ... but nowhere is that specified... (and it should not either)
[21:44] <ordnungswidrig> ah, I see. the concrete list of formats i not specified?
[21:45] <algermissen> yes - it can;t because the server cannot be constrained
[21:45] <ordnungswidrig> nice.
[21:45] <algermissen> (and hard to sell to CIOs, BTW)
[21:45] <ordnungswidrig> but open
[21:45] <algermissen> 406 Not acceptable is the issue here
[21:45] <ordnungswidrig> so how can I build a client which "talks" opensearch?
[21:46] <algermissen> by reading the spec and deciding how clever you want to be
[21:46] <ordnungswidrig> I must "hope" that the server sends a representation the user agent can understand?
[21:46] <algermissen> and how much time you have
[21:46] <algermissen> yes - hope is a good term
[21:46] <algermissen> ;-)
[21:46] <ordnungswidrig> hope like in optimistic concurrency control
[21:46] <algermissen> On the Web that is all fine
[21:47] <algermissen> but my quest is to make it enterprise friendy
[21:47] <algermissen> aka 'planable' and 'acountable'
[21:47] <ordnungswidrig> the web is a web of hope. hope that the link is not borken, that my browser can understand the reponse, that the connection is working, that the proxy is stable
[21:47] <ordnungswidrig> back to my core issue
[21:48] <ordnungswidrig> I "enrich" a browser to understand my custom media types.
[21:49] <algermissen> hope, yes - and Roy's perma-statement is IMHO: "in a networked environment hope is all you have anyhow - no IDL-implied feeling of control will change that. control is an illusion)
[21:49] <ordnungswidrig> But how should a GUI handle the case when I receive an unexpected media type, but one I can render.
[21:49] <ordnungswidrig> A browser receiving text/html from an image tag's src will render a "broken image"
[21:50] <algermissen> I guess so
[21:50] <algermissen> you could send the text/html to a popup HTML pane
[21:50] <ordnungswidrig> A classical HTML application which receives a catalogue representation instead of the order rerpesentation (as expected by the actor) will render the order.
[21:51] <algermissen> Ah! No you mix things up :-)
[21:51] <ordnungswidrig> You see the "static HTML" approach handles this differently
[21:51] <algermissen> the HTML application (the browser) never expected a catalogue
[21:51] <algermissen> it expected HTML!
[21:51] <ordnungswidrig> yes, I mean a HTML representation of a catalog resource
[21:51] <algermissen> all it does it make that steady state available to the user
[21:52] <algermissen> there ends the responsibility of the user agent
[21:52] <algermissen> that is why it never said Accept: catalogue in the first place
[21:52] <ordnungswidrig> yes, so the browser is fine with any HTML it receives, only the user might by confused if it expected something else
[21:52] <algermissen> ricght. but it is outside the realm of the user agent
[21:53] <algermissen> because that one just processes and makes accessible the app state
[21:53] <ordnungswidrig> exactly! the advantage of this is: even if the user is confused by "irrational" relations it can go on and try another way to reach his goeal
[21:53] <algermissen> Yeah - even the body of an error response
[21:53] <algermissen> is an application state
[21:54] <algermissen> (on the web often with links to follow)
[21:54] <algermissen> (like 404 pages with normal site menu)
[21:54] <ordnungswidrig> in the JS-UA case the UA has to differentiate between "expected" representations and unexpected ones.
[21:54] <algermissen> .. unfortunately the human Web obfuscates much of this
[21:54] <ordnungswidrig> yes
[21:55] <algermissen> ideally, there are no unexpected ones but 406 respionses
[21:55] <algermissen> but I guess 200 + html for an Accept product request should be seen as 406
[21:56] <ordnungswidrig> so when the actor presses a "refresh catalogue" control in the GUI control which shows a catalogue then the UA will send an accect: xml/vnd.com.mycompany.product+xml ?
[21:56] <algermissen> you mean Accept: catalogue?
[21:57] <ordnungswidrig> Accept header, with anything the UA considers a valid media type for a catalogue
[21:57] <algermissen> yes - ok
[21:58] <ordnungswidrig> or it can accept anything and try to interpret the response intelligently: if it's a catalog refresh catalog control, if it's a product then show (or update) a product control, if it's an order show and order control etc.
[21:58] <ordnungswidrig> like a web browser sending */*
[21:58] <algermissen> yes, exactly
[21:59] <ordnungswidrig> but this can be confusing. imagine you have display to products and a catalog control. then you refresh the catalogue (or select a sub-category or like that) but the server responds with a product.
[21:59] <algermissen> did you see my stuff on Jersey client side, BTW?
[21:59] <ordnungswidrig> algermissen: I skimmed over it
[22:00] <algermissen> so, you need to be careful not to make it confusing
[22:00] <algermissen> the view-idea in Jersey is very much based on all this
[22:00] <algermissen> your catalogue-display-pane could be a view
[22:01] <ordnungswidrig> I think a honest 406 is worth its weight
[22:01] <algermissen> yes, embrace it :-)
[22:01] <algermissen> I like to picture a machine reaction to 406 as follows
[22:01] <ordnungswidrig> REST on the client is much less understood than REST on the server...
[22:02] <algermissen> on 406 send request for change to service help desk directly, providing 406 body as hints what to do to asap
[22:03] <algermissen> fix client to handle the medi atypes the server *can* send
[22:03] <ordnungswidrig> client helpdesk?
[22:03] <algermissen> that is much(!) better than to call the debugging team in a non-REST integration
[22:03] <ordnungswidrig> ok, so the responsibility os on the client
[22:03] <algermissen> scenario
[22:03] <ordnungswidrig> nice idea
[22:04] <ordnungswidrig> you better hope your helpdesk application does not respond with a 416 then :)
[22:05] <algermissen> see http://www.nordsc.com/blog/?p=147 on client's fault (a bit of a rant, though) :-)
[22:05] <algermissen> looks up 416 to understand joke ;-)
[22:05] <algermissen> Hmm 416 is a Range error - lost me on the Joke
[22:06] <ordnungswidrig> oh boy, I meant 415 of course
[22:06] <algermissen> Ah - LOL :-)
[22:06] <ordnungswidrig> it took me some years to understand that all response codes are equal. (200 is a litle more equal)
[22:07] <algermissen> yes - years - I look at all this since 2003 or so
[22:07] <algermissen> and still had my last insights last week - crap
[22:08] <ordnungswidrig> hmm, I remember early html which had no forms but a "index query" or like that.
[22:08] <ordnungswidrig> we all though gopher would make it
[22:08] <algermissen> it was only when I decided to put *all* of OO away when I saw yet more light :-)
[22:08] <algermissen> uhh - too early for me
[22:08] <algermissen> I skipped the early days :-)
[22:08] <ordnungswidrig> you know the presentation of rich hickey about oo, identity and state? ("you're doing it wrong") It's epic
[22:09] <algermissen> no - gotta link?
[22:09] <algermissen> googling...
[22:09] <ordnungswidrig> google for clojure infoq
[22:09] <ordnungswidrig> rich explains the ideas behind clojure
[22:10] <ordnungswidrig> an eye opener for me, like the idea of REST was for me.
[22:10] <ordnungswidrig> http://www.infoq.com/presentations/hickey-clojure
[22:10] <algermissen> got it
[22:10] <algermissen> ]
[22:11] <ordnungswidrig> http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
[22:11] <ordnungswidrig> I think this one is more about the state and identity thing
[22:11] <algermissen> know what - I think I need to go to bed, sorry
[22:11] <ordnungswidrig> me too, you're from germany as well?
[22:12] <algermissen> yep - hamburg.
[22:12] <ordnungswidrig> ulm
[22:12] <algermissen> awaiting 1 degree this night WTF?
[22:12] <ordnungswidrig> na denn, gute nacht :-)
[22:12] <algermissen> ja, gute nacht :-)
[22:12] ordnungswidrig (Adium@p5B1745B1.dip.t-dialin.net) left #rest.
[22:24] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest.
[22:39] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) left irc: Ping timeout: 245 seconds
[22:50] <mamund> /me has other stuff to do, you're all on your own now!
[23:05] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest.
[23:06] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing
[23:13] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) left irc: Quit: avdi
[23:13] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest.
[23:16] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) left irc: Client Quit
[23:16] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest.
[23:52] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) left irc: Ping timeout: 245 seconds
[00:00] --- Thu May 6 2010