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

[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] <algermissen> hello?
[13:25] <mikekelly> hi
[13:25] <mikekelly> algermissen: any further thoughts on ian's comments on steady states?
[13:25] <algermissen> not yet
[13:25] <algermissen> working on my client side prog model
[13:26] <algermissen> thinking about what the significance is of the steps in a multi-step goal
[13:27] <algermissen> putting in a step actually only makes sense when the step influence another step client takes
[13:27] <mikekelly> even then you have code on demand to simplify the solution
[13:27] <algermissen> e.g. looking at a catalogue resource anly makes sense if I do not know what exactly I will buy yet
[13:28] <algermissen> 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] <mikekelly> 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] <mikekelly> well I think, personally that most of the tools are already pretty good for HTML + javascript :-)
[13:30] <mikekelly> but that's just me :D
[13:30] <algermissen> :-)
[13:51] <algermissen> when I am implementing a client: what do I know about the server that I can use to do the implementation?
[13:51] <algermissen> ===> I know the media types and link rels etc. the server uses
[13:52] <algermissen> ===> I know that I will have some start URI
[13:52] <algermissen> ===> more I do not know
[13:53] <algermissen> lunch munch..
[14:13] <algermissen> munched lunch
[14:51] mamund_ pops in, pours coffee, digs in
[14:53] <mamund_> mikekelly, altermissen: re-reading ian/jan's convo has helped me clear up my thinking on states (steady and otherwise).
[14:54] <mamund_> 1) a resource represents a steady-state.
[14:54] <mamund_> 2) clients can be expected to attempt to illicit a response for any resource that has been published via a resource id.
[14:55] <mamund_> 3) clients can be expected to cut off communication w/ a server at the end of any resource response.
[14:55] <mamund_> 4) 2 & 3 represent Fielding's steady-states that can be treated as start and/or end points
[14:56] <mamund_> 5) buliding workable applications usually means stringing together multiple resource interactions.
[14:57] <mamund_> 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] <mamund_> these interim resources represent "transient" states in the _application_ flow.
[14:58] <mamund_> 7) while it is true that clients may attempt to start/stop anywhere along this application flow arc,
[14:59] <mamund_> servers should be prepared to send proper responses when clients attempt to start somewhere along the arc at an interim resource...
[14:59] <mamund_> and need to be prepared to handle cases where clients stop before reaching the application flow end point.
[15:00] <mamund_> this is what i have in mind when i talk about SS -> t[0..n] -> SS
[15:00] <mamund_> does this make sense?
[15:03] <algermissen> yes (though I would not agree with all of it :-)
[15:03] <algermissen> Intersting question is I think why a client needs an intermediate state?
[15:03] <mamund_> algermissen: i appreciate that.
[15:03] <algermissen> asked that a couple of hours ago
[15:04] <mamund_> yes, that is a good question.
[15:04] <algermissen> client only needs that state if it affects it sown path to the goal
[15:04] <algermissen> if it needs to make a decision
[15:04] <mamund_> 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] <algermissen> e.g. looking at a catalogue resource anly makes sense if I do not know what exactly I will buy yet
[15:05] <mamund_> 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] <algermissen> 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] <mamund_> yes, if you already know all that, this is fine. i can't ensure my real life clients alrady know that
[15:06] <mamund_> 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] <mamund_> sometimes i can, and that's great.
[15:08] <algermissen> 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] <algermissen> this is IMHO an interesting point in client development
[15:08] <mamund_> hmm...
[15:08] <algermissen> its like a dependency tree of steady states
[15:09] <mamund_> yes, i see the dependency tree of states.
[15:09] <mamund_> Fielding once encouraged folks to "work backwards" when developing RESTful apps
[15:09] <algermissen> oak?
[15:09] <mamund_> i try to do that
[15:09] <algermissen> yes, need to digg up the post
[15:10] <algermissen> "what do you wantthe state of the system to be after...." right?
[15:10] <mamund_> 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] <mamund_> yeah, i think that's it
[15:11] <mamund_> 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] <mamund_> 400 the client and be done with it, or supply the client w/ a hypermedia link that points to the catalog, etc.
[15:12] <algermissen> hmm, I guess that is too much of AI. the client must be more specific
[15:12] <mamund_> the client?
[15:12] <algermissen> if client has no idea of catalog shopping, sending the link wont help
[15:13] <algermissen> going through a catalogue only makes sense when having selecion rules
[15:14] <mamund_> ok, i see. maybe the specifics of the example i gave don't work for an m2m experience.
[15:14] <algermissen> 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] <mamund_> yes, as you say, more needs to be specified for the client. and the server must be able to properly react.
[15:15] <algermissen> 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] <mamund_> yes, i think mikekelly mentions this, too. the human-powered web is deeply ingrained in our thinking.
[15:18] <algermissen> ...assimilated into the collective machine ...
[15:19] <mamund_> hehehe
[15:20] <algermissen> i wonder to what extend the Internet has accelerated the pace of human innovation
[15:20] <mamund_> 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] <algermissen> like - if you can clearly see it on a graph
[15:20] <mamund_> where am i tripping up?
[15:21] <mamund_> lots of speculation on how information is affecting evolution.
[15:22] <algermissen> 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] <algermissen> 5) Dunno but I think that many business functions can be achieved in a single request (no hops)
[15:23] <algermissen> hops are a phenomenon of the human web
[15:23] <algermissen> maybe
[15:23] <mamund_> i understand about 5, i think...
[15:24] <algermissen> interim resource/transient states - I thinkthe notion is 'useless'/'meaningless/"unecessary" (sorry :-)
[15:24] <mamund_> your point is that interim resources are an artifact of humans on the web; that in m2m cases, these are not needed.
[15:24] <mamund_> i appreciate this.
[15:24] <algermissen> no, the point is that any primary resource leads you toa steady state
[15:24] <algermissen> == a possible entry point
[15:24] <mamund_> you think interim resources are really, eveidence of bad design, maybe?
[15:25] <mamund_> "primary resource"?
[15:25] <algermissen> yes, bad design
[15:25] <algermissen> "primary resource"? the one that causes the steady state (e.g. the Web page) - the root resource of a steady state
[15:25] <algermissen> roy says "primary representation" for that
[15:26] <mamund_> yeah, his example of steady-state is when all the state transfers identified w/ in the primary resource are complete enough, right?
[15:26] <algermissen> exposing a resource state that has only temporary validity (not only the state but the whole concept)
[15:27] <algermissen> yes. Web page done loading
[15:27] <algermissen> (priecisely: when all response bodies are available as a stream)
[15:27] <algermissen> (complete download not needed, state is steady once all responses return
[15:28] <mamund_> do you see any validity in my attempt to distinguish resource interactions from application interactions? similar to ian's "orchestration", i think.
[15:29] <algermissen> 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] <algermissen> which I will then probably understand
[15:29] <algermissen> uhh - what an open space for interpretation
[15:29] <mamund_> np, many things to cover along with trying to earn a living, too<g>.
[15:30] <mamund_> thanks for your feedback. i appreciate your directness.
[15:31] <mamund_> i hope to get feedback from mikekelly on this, too.
[15:32] <algermissen> need to do some work - thanks for aiding my brainstorm
[15:35] <mamund_> 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] 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] mamund_ waves 'hi' to Toba_
[19:47] <Toba_> PUT http://mamund_/hello
[19:48] <mamund_> LOL
[19:49] <mamund_> cool domain, btw
[19:53] <Toba_> thanks man
[19:53] <Toba_> i use cons.truct.org and des.truct.org on it ;)
[19:54] <mamund_> yeah - sweet. in. recon. lots of possibilities
[20:07] <Toba_> I hadn't even thought of recons.truct!
[20:07] <Toba_> thanks dude
[20:08] <Toba_> oooh. obstruct
[20:09] <mamund_> heh
[20:09] <mamund_> yep
[23:10] algermissen (~algermiss@p54905078.dip.t-dialin.net) left irc: Quit: RESTing
[00:00] --- Thu Feb 18 2010