[00:20] bradley-holt (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Ping timeout: 245 seconds [01:45] josemoreira (~jmoreira@a213-22-159-52.cpe.netcabo.pt) left irc: Quit: josemoreira [02:10] KevBurnsJr (~kevburnsj@c-67-161-65-81.hsd1.ca.comcast.net) left irc: [05:04] MrMojoRisin (~kane@116.68.72.193) joined #rest. [05:04] insanekane (~kane@116.68.72.193) left irc: Remote host closed the connection [07:57] algermissen (~algermiss@p54905078.dip.t-dialin.net) joined #rest. [08:05] algermissen (~algermiss@p54905078.dip.t-dialin.net) left irc: Quit: Bye [10:28] mamund_ (mamund@frost.nullshells.net) joined #rest. [10:31] cods (~cods@rsbac/developer/cods) left irc: Disconnected by services [10:33] mamund (mamund@2001:49f0:1017::2) got netsplit. [10:33] cods_ (~cods@tuxee.net) joined #rest. [10:35] cods_ (~cods@tuxee.net) left irc: Client Quit [10:40] cods (~cods@rsbac/developer/cods) joined #rest. [10:44] mamund (mamund@2001:49f0:1017::2) got lost in the net-split. [10:53] algermissen (~algermiss@p54905078.dip.t-dialin.net) joined #rest. [10:54] hello? [13:25] hi [13:25] algermissen: any further thoughts on ian's comments on steady states? [13:25] not yet [13:25] working on my client side prog model [13:26] thinking about what the significance is of the steps in a multi-step goal [13:27] putting in a step actually only makes sense when the step influence another step client takes [13:27] even then you have code on demand to simplify the solution [13:27] e.g. looking at a catalogue resource anly makes sense if I do not know what exactly I will buy yet [13:28] code on demand is interesting for m2m clients but that is for anotgher day :-) would require some sort of common client API that the code on demand could work against, or? [13:28] in one app I have actually dumped the whole of a form (with all possible routes) in one HTML doc and then split it up using javascript [13:29] well I think, personally that most of the tools are already pretty good for HTML + javascript :-) [13:30] but that's just me :D [13:30] :-) [13:51] when I am implementing a client: what do I know about the server that I can use to do the implementation? [13:51] ===> I know the media types and link rels etc. the server uses [13:52] ===> I know that I will have some start URI [13:52] ===> more I do not know [13:53] lunch munch.. [14:13] munched lunch [14:51] Action: mamund_ pops in, pours coffee, digs in [14:53] mikekelly, altermissen: re-reading ian/jan's convo has helped me clear up my thinking on states (steady and otherwise). [14:54] 1) a resource represents a steady-state. [14:54] 2) clients can be expected to attempt to illicit a response for any resource that has been published via a resource id. [14:55] 3) clients can be expected to cut off communication w/ a server at the end of any resource response. [14:55] 4) 2 & 3 represent Fielding's steady-states that can be treated as start and/or end points [14:56] 5) buliding workable applications usually means stringing together multiple resource interactions. [14:57] 6) application flows (multiple resource interactions) will have a valid start and a valid stop and are likely to have interim resources along the way, [14:57] these interim resources represent "transient" states in the _application_ flow. [14:58] 7) while it is true that clients may attempt to start/stop anywhere along this application flow arc, [14:59] servers should be prepared to send proper responses when clients attempt to start somewhere along the arc at an interim resource... [14:59] and need to be prepared to handle cases where clients stop before reaching the application flow end point. [15:00] this is what i have in mind when i talk about SS -> t[0..n] -> SS [15:00] does this make sense? [15:03] yes (though I would not agree with all of it :-) [15:03] Intersting question is I think why a client needs an intermediate state? [15:03] algermissen: i appreciate that. [15:03] asked that a couple of hours ago [15:04] yes, that is a good question. [15:04] client only needs that state if it affects it sown path to the goal [15:04] if it needs to make a decision [15:04] in real life (so far anyway) i have not been able to complete each of my customer's requests for features in a single state interaction [15:05] e.g. looking at a catalogue resource anly makes sense if I do not know what exactly I will buy yet [15:05] while many are simply an update of an existing resource or a single state transition, some require multiple steps, the ability to stop along the way and restart the work, etc. [15:05] yes, but if you know you want 5 parts of P1 and 2 of P2 you just send the order you only need the catalogue if you have a proce limit [15:06] yes, if you already know all that, this is fine. i can't ensure my real life clients alrady know that [15:06] i can't ensure my real life clients have a scriptable client that allows multiple sub-interactions to all occur on the client w/o server interaction. [15:07] sometimes i can, and that's great. [15:08] consider this: when you develop your client (machine client) you inevitably decide which of those states you need to be in because this is where you code decision points [15:08] this is IMHO an interesting point in client development [15:08] hmm... [15:08] its like a dependency tree of steady states [15:09] yes, i see the dependency tree of states. [15:09] Fielding once encouraged folks to "work backwards" when developing RESTful apps [15:09] oak? [15:09] i try to do that [15:09] yes, need to digg up the post [15:10] "what do you wantthe state of the system to be after...." right? [15:10] as you said, if you know yo uneed 5 P1 and 2P2, just POST that to the "purchase" resource and you're all set. [15:10] yeah, i think that's it [15:11] however, if the client attempts a POST w/o the proper shopping cart information already supplied, the server must decide how to handle this... [15:12] 400 the client and be done with it, or supply the client w/ a hypermedia link that points to the catalog, etc. [15:12] hmm, I guess that is too much of AI. the client must be more specific [15:12] the client? [15:12] if client has no idea of catalog shopping, sending the link wont help [15:13] going through a catalogue only makes sense when having selecion rules [15:14] ok, i see. maybe the specifics of the example i gave don't work for an m2m experience. [15:14] ok, I could see that client posts order, itemsnot available at proposed price, server answers with catalogue, client applies rules to alter order and re-submits. [15:15] yes, as you say, more needs to be specified for the client. and the server must be able to properly react. [15:15] happens to me often because the human-use patterns of the web (searcing around, browsing around) are so in our bones - but they are notinhg for machines [15:17] yes, i think mikekelly mentions this, too. the human-powered web is deeply ingrained in our thinking. [15:18] ...assimilated into the collective machine ... [15:19] hehehe [15:20] i wonder to what extend the Internet has accelerated the pace of human innovation [15:20] so, i ask your indulgence. in my attempt to get a handle on this idea of applications that have stable and interim resources... [15:20] like - if you can clearly see it on a graph [15:20] where am i tripping up? [15:21] lots of speculation on how information is affecting evolution. [15:22] 2+3 - a stedy state is reached after a series of automatic requests. one of the resources being the source of the primary representation (e.g. the HTML doc) [15:22] 5) Dunno but I think that many business functions can be achieved in a single request (no hops) [15:23] hops are a phenomenon of the human web [15:23] maybe [15:23] i understand about 5, i think... [15:24] interim resource/transient states - I thinkthe notion is 'useless'/'meaningless/"unecessary" (sorry :-) [15:24] your point is that interim resources are an artifact of humans on the web; that in m2m cases, these are not needed. [15:24] i appreciate this. [15:24] no, the point is that any primary resource leads you toa steady state [15:24] == a possible entry point [15:24] you think interim resources are really, eveidence of bad design, maybe? [15:25] "primary resource"? [15:25] yes, bad design [15:25] "primary resource"? the one that causes the steady state (e.g. the Web page) - the root resource of a steady state [15:25] roy says "primary representation" for that [15:26] yeah, his example of steady-state is when all the state transfers identified w/ in the primary resource are complete enough, right? [15:26] exposing a resource state that has only temporary validity (not only the state but the whole concept) [15:27] yes. Web page done loading [15:27] (priecisely: when all response bodies are available as a stream) [15:27] (complete download not needed, state is steady once all responses return [15:28] do you see any validity in my attempt to distinguish resource interactions from application interactions? similar to ian's "orchestration", i think. [15:29] ian has a point I did not havethe time to dig into but whcih I find interesting. I guess it relates to your point [15:29] which I will then probably understand [15:29] uhh - what an open space for interpretation [15:29] np, many things to cover along with trying to earn a living, too. [15:30] thanks for your feedback. i appreciate your directness. [15:31] i hope to get feedback from mikekelly on this, too. [15:32] need to do some work - thanks for aiding my brainstorm [15:35] you're most welcome. take care. [15:53] bradley-holt (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [16:15] bradley-holt_ (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [16:16] bradley-holt (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Ping timeout: 245 seconds [16:16] Nick change: bradley-holt_ -> bradley-holt [19:14] KevBurnsJr (~kevburnsj@c-67-161-65-81.hsd1.ca.comcast.net) joined #rest. [19:26] Toba_ (~eastein@balin.truct.org) joined #rest. [19:46] Action: mamund_ waves 'hi' to Toba_ [19:47] PUT http://mamund_/hello [19:48] LOL [19:49] cool domain, btw [19:53] thanks man [19:53] i use cons.truct.org and des.truct.org on it ;) [19:54] yeah - sweet. in. recon. lots of possibilities [20:07] I hadn't even thought of recons.truct! [20:07] thanks dude [20:08] oooh. obstruct [20:09] heh [20:09] yep [23:10] algermissen (~algermiss@p54905078.dip.t-dialin.net) left irc: Quit: RESTing [00:00] --- Thu Feb 18 2010