#rest on irc.freenode.net 2011-11-17 (txt)

[00:19] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[00:20] Wombert (~Wombert@84.233.128.147) joined #rest.
[00:21] Wombert (~Wombert@84.233.128.147) left irc: Client Quit
[00:35] ivanfi (~ivanfi@62.159.77.167) joined #rest.
[02:06] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[02:24] Blazeix (~Blazeix@71.74.190.197) left irc: Read error: Operation timed out
[02:24] Blazeix (~Blazeix@71.74.190.197) joined #rest.
[02:24] kevwilde (~kevwilde@igwe16.vub.ac.be) joined #rest.
[02:25] <kevwilde> Howdy, i'm creating a REST api, but i need an url that allows me to send a mail, but /mail is a verb, what do you think is the best strategy to be as close to REST as possible?
[02:41] DracoBlue1 (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[02:43] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Ping timeout: 252 seconds
[02:44] <Ngarthl> kevwilde: URI design is orthogonal to REST. REST does not care.
[02:44] <Ngarthl> mail is both a verb and a noun
[02:45] <kevwilde> so i can have a /mail which only takes a POST method?
[02:45] <Ngarthl> if you use REST in context of HTTP yes
[02:45] <Ngarthl> REST != HTTP
[02:46] <kevwilde> we're using it in an HTTP context, i believe this is the most common practice, do you have examples of REST in other contexts?
[02:48] <Ngarthl> it is possible to to do REST over a multitude of protocols. HTTP is the most common. FTP is another
[02:49] <Ngarthl> REST is an archtectual style.
[02:49] <Jarda> and IMO POSTing to /mail isn't very resourceful, but that's just me
[02:50] <Jarda> (unless it creates a mail-resource)
[02:50] <kevwilde> Jarda: how would you handle the case?
[02:50] <Ngarthl> It must be hypermedia driven
[02:50] <Jarda> kevwilde: I would maybe put my client actually handle the mail sending
[02:51] <Jarda> or then the mailing should be a side effect
[02:51] <Jarda> but I don't get why you would want to have a "mail" resource
[02:51] <kevwilde> Jarda: the problem is that the API is of a server containing all business logic, sending and resending a mail is part of the business scope
[02:52] <kevwilde> sending is a side effect, but resending the mail should be possible too
[02:52] <Jarda> kevwilde: ok, so then you actually have mail-resources
[02:52] <Jarda> and it makes sense
[02:52] <Jarda> because every sent mail should have an identifier
[02:52] <Jarda> so you don't have a resource sending mails
[02:52] <kevwilde> i don't save them in my database, though
[02:53] <Jarda> but you have a collection of mail-items
[02:53] <Jarda> how can they be re-sent if you don't store them?
[02:53] <kevwilde> i have a collection of tickets, those can be sent by mail
[02:54] <Jarda> eh
[02:54] <kevwilde> they get sent when created, but i should be able to resend the tickets
[02:54] <Ngarthl> ah. that is quite possible
[02:54] <DracoBlue1> do you mean some kind of "resend"-button, to notifiy everyone who is connected to the ticket?
[02:54] DracoBlue1 -> DracoBlue
[02:54] <Jarda> you can do whatever you want, but /tickets/123/mail isn't REST, its's RPC
[02:54] <Jarda> (IMO)
[02:54] <kevwilde> DracoBlue: yes, something like that
[02:55] <kevwilde> Jarda: if there is no real REST way, i'll have to go REST-RPC hybrid-like
[02:55] <DracoBlue> what about POST to /tickets/123/reminders or something like that?
[02:55] <Ngarthl> each ticket SHOULD have a <link rel="send-mail" href="fooo"/> and that resource could for instance take a list of tickets, maybe in the form of text/uri-list"
[02:55] <Jarda> and afterall, it doesn't really matter, as long as the identifier is identified by hypermedia
[02:56] <kevwilde> Ngarthl: i'm not writing HTML, i'm writing an HTTP API
[02:56] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Remote host closed the connection
[02:56] <Jarda> kevwilde: hypermedia isn't restricted to html..
[02:56] <kevwilde> i'm just writing the API backend
[02:56] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[02:56] <Jarda> ever heard of HATEOAS?
[02:56] <Jarda> if not, then our serfice isn't REST
[02:56] <Jarda> *your
[02:57] <Ngarthl> Jarda: hearing about it ain't enough ;)
[02:57] <Jarda> Ngarthl: :)
[02:58] <Ngarthl> JSON + HTTP != REST
[02:58] <Ngarthl> Hypermedia + HTTP == REST
[02:58] <Ngarthl> very simplified
[02:58] <Ngarthl> Hypermedia MAY of course be encoded in JSON, but JSON in itself is not. The same with XML.
[03:00] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit
[04:11] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[04:14] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit
[04:24] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[04:27] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit
[04:31] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 260 seconds
[04:31] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[05:00] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[05:49] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[05:50] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Client Quit
[05:56] tomayac (~tomayac@213.61.101.1) joined #rest.
[06:02] tomayac (~tomayac@213.61.101.1) left irc: Quit: tomayac
[06:03] tomayac_ (~tomayac@213.61.101.1) joined #rest.
[06:19] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest.
[06:21] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove
[06:24] <mikekelly> mamund: did you see I made a pretty picture for HAL ?
[06:27] <bigbluehat> mikekelly: links? :)
[06:28] <mikekelly> http://stateless.co/info-model.png
[06:29] <mikekelly> I think that makes sense
[06:29] <mikekelly> it makes sense to me
[06:46] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) joined #rest.
[06:48] <mikekelly> mamund: URI pattern craziness from joe gregorio https://plus.google.com/u/0/118148240205592032989/posts/Vxu7xgaBnnc
[07:01] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[07:21] mamund slides in
[07:22] <mamund> mikekelly: nice pic<g>
[07:22] <mamund> interesting rendering of href as "outside, but related"?
[07:24] <mamund> mikekelly: missed the plus convo, thanks for the pointer.
[07:26] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[07:26] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit
[07:26] <mikekelly> mamund: did that href bit make sense
[07:28] <mikekelly> looks like I'm wrong because I haven't made 100 google APIs
[07:28] <mikekelly> fair enough.. :|
[07:32] <mamund> LOL, i added my comment, let's see what comes back
[07:38] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[07:42] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[07:53] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) left irc: Quit: brb
[07:55] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Quit: Leaving.
[07:57] <mikekelly> sigh.
[07:58] <mikekelly> mamund: that is a poor response you've been given, imo
[07:58] <mikekelly> and completely misses the previous point about caching
[07:58] <mikekelly> that is EXACTLY what caching is for..
[07:58] <mikekelly> :|
[08:04] <mikekelly> suprised you agreed with that point mamund
[08:04] <mikekelly> :)
[08:15] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Quit: bradley-holt
[08:24] <mikekelly> I hate discussions like this because I never know if people think I have a point or I'm just arguing for the sake of it
[08:25] <mikekelly> I can honestly say I actually do believe I am making a valid point
[08:25] <mikekelly> sorry if I'm coming across all Eric'y
[08:28] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[08:29] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Quit: Leaving.
[08:30] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest.
[08:30] <mamund> LOL
[08:31] <mamund> mikekelly: i, too, think the response is a bit of 'weak sauce' but...
[08:31] <mamund> i'd like to hear jg lay out the thinking there w/o too much harping on my end
[08:32] <mamund> very interested in what the "value judgments" are for GOOG (i.e. bandwidth, etc.) and seeing how that affects the way they expect client devs and others to bgehave
[08:32] <mamund> actually, it's nice that jg is willing to carry on this thread
[08:32] <mamund> all valuable stuff, imo.
[08:32] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[08:32] <mikekelly> right, but afaict it's based on false assumptions about how optmisations hve to be applied
[08:32] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest.
[08:32] <KevBurnsJr> mikekelly: turn that diagram 90" counter clockwise.
[08:32] <mikekelly> i.e they aren't using caching
[08:33] <mikekelly> KevBurnsJr: ok
[08:34] <mikekelly> CCW or CW ?
[08:34] <mikekelly> makes more sense cw
[08:34] <mikekelly> or I need to swap state and links
[08:34] <mikekelly> yeah I need to rotate 90 CCW and swap the likn and state around
[08:35] <mamund> mikekelly: yeah, i totally see your point...
[08:35] <mamund> here's something i suspect is in their heads...
[08:35] <mamund> "clients stink at honoring caching, we need to 'optimize' that problem out by making the responses as thiny as possible", etc.
[08:36] <mikekelly> perpetuation
[08:36] <mikekelly> cool.
[08:36] <mikekelly> they own a good chunk of the mobile market
[08:36] <mikekelly> they can easily do something about that
[08:36] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Client Quit
[08:37] <mikekelly> my first time having a proper convo on google+
[08:37] <mikekelly> it's pretty good
[08:37] <mikekelly> way better than twitter, anyway :)
[08:44] <KevBurnsJr> mikekelly: http://d.kevburnsjr.com/HAL.png
[08:44] <KevBurnsJr> CCW
[08:45] <KevBurnsJr> (I clearly arrived at the office too early this morning)
[08:46] <KevBurnsJr> reason being that when CCW, it more clearly emulates the structure of a HAL doc
[08:46] <KevBurnsJr> in fact....
[09:08] <KevBurnsJr> I saw something like this in a presentation recently
[09:08] <KevBurnsJr> http://d.kevburnsjr.com/resource_blot.jpg
[09:11] <KevBurnsJr> png also http://d.kevburnsjr.com/resource_blot.png
[09:21] tomayac_ (~tomayac@213.61.101.1) left irc: Quit: tomayac_
[09:27] <mikekelly> :o
[09:27] <mikekelly> KevBurnsJr: who gave the presentation ?
[09:32] <mamund> huh: https://twitter.com/#!/MTAMMO22
[09:37] <mikekelly> erm
[09:37] <mikekelly> he seems pretty special
[09:58] bigbluehat (~bigblueha@adsl-74-177-97-140.gsp.bellsouth.net) joined #rest.
[10:28] ivanfi (~ivanfi@62.159.77.167) left irc: Quit: Leaving.
[11:04] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest.
[11:05] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left #rest.
[11:13] Guest24321 (~scott@78.129.202.63) got netsplit.
[11:13] mamund was away
[11:14] Guest45999 (~scott@78.129.202.63) joined #rest.
[11:14] <mamund> mikekelly: wonder if i need to mark my twitter feed as "verified account"<g>
[11:24] Guest24321 (~scott@78.129.202.63) got lost in the net-split.
[12:21] <mamund> mikekelly, KevBurnsJr : i like the idea of representiong a media type in a visual way.
[12:22] <mamund> i am soooo "verbal" i don't always think about this POV
[12:22] <mamund> and, by *not* thinking about it in a visual way, sometimes have a harder time communicating my ideas.
[12:41] technoweenie (~technowee@host-86-220-9-69.midco.net) left irc: Remote host closed the connection
[13:31] rxMokka (~usXr@unaffiliated/rxkaffee) joined #rest.
[13:31] rxMokka (~usXr@unaffiliated/rxkaffee) left #rest ("WeeChat 0.2.5").
[13:41] <trygvis> is there a content type for md5 files?
[13:43] <trygvis> or what about cryptographic signatures?
[13:50] <trygvis> there's application/pgp-signature, application/pgp-keys and application/pgp-encrypted at least
[14:27] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove
[14:33] bigbluehat (~bigblueha@adsl-74-177-97-140.gsp.bellsouth.net) left irc: Quit: Leaving.
[14:54] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[15:06] mark_burns (~mark@cpc1-dals15-2-0-cust635.hari.cable.virginmedia.com) joined #rest.
[15:07] steveklabnik waves at mark_burns
[15:07] <mark_burns> hi
[15:08] <mark_burns> so, yeah to continue that conversation. I'm not sure I understand the idea of code-on-demand
[15:09] <mark_burns> it seems to introduce extra coupling
[15:09] <mark_burns> if i was to provide a service then i think i should not enforce a language constraint on the client
[15:11] <steveklabnik> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7
[15:11] <steveklabnik> for reference
[15:12] <steveklabnik> anyway, so yes. it'd add some sort of language constraint onto a client.
[15:12] <steveklabnik> that may or may not be worth it
[15:13] <steveklabnik> in many cases, it can help with things like scale
[15:13] <steveklabnik> since you offload work onto a client
[15:13] <steveklabnik> but, clients without the appropriate runtime are screwed.
[15:17] <mark_burns> i think i'm having a hard time understanding what a true REST API (including the HATEOAS constraint) that might be consumed by javascript would be considering that it may also output javascript
[15:17] mamund was away
[15:17] steveklabnik waves hello to mamund
[15:17] <mark_burns> i can cope with the idea of abandoning JSON as a communications protocol because it makes the HATEOAS constraint cumbersome
[15:17] mamund waves back
[15:18] <steveklabnik> mark_burns: hmm. why would that be odd?
[15:18] <steveklabnik> that'd be the easy case
[15:18] <steveklabnik> since you'd have a JS runtime installed for sure
[15:19] <mark_burns> but then parsing XHTML as a javascript client, and also receiving javascript to execute on demand
[15:20] <mark_burns> i'm fine with the concept of a server and client written by the same person/group working hand in hand in the way a complex js web app does
[15:21] <mark_burns> but providing more generic services, that might be consumed by a complex js client that also then receives more js initially is boggling my mind
[15:21] <steveklabnik> xhtml is not the only options
[15:21] <steveklabnik> option
[15:21] <mark_burns> ok so how do you tackle the forms issue in a universally well understood way?
[15:22] <mark_burns> say for JSON APIs?
[15:22] <steveklabnik> you couldnt use json
[15:22] <steveklabnik> you'd have to use something like HAL
[15:22] <mamund> mark_burns: check out my COllection+JSON for an example
[15:22] <steveklabnik> or collection+json
[15:22] <mamund> you can define a "form" in any media type/format
[15:23] <mamund> mark_burns: does that help?
[15:23] <mamund> i mean, is that really what you were asking about<g>
[15:23] <mark_burns> just reading http://amundsen.com/media-types/collection/format/ is that what you mean?
[15:24] <mamund> yeah
[15:24] <mamund> so i mention that because that design _does_ have something
[15:24] <mamund> that mimics HTML.FORM
[15:24] <mamund> it's just one design, tho. nothing standard|official|required|etc.
[15:25] <mamund> HTML defined a standard for "parameterized transitions" <g>
[15:25] <mamund> they use a tag named FORM with sub elements (INPUT,SELECT, TEXTAREA)
[15:26] <steveklabnik> mamund: i've been working on a gem to help ruby clients use hypermedia apis, and mark_burns has been messing around with an idea.
[15:26] <mamund> and the client is hard-coded to convert that data into a media type (application/x-www-formurlencoded) when sending via POST.
[15:26] <mamund> that's all
[15:26] <mamund> ahhh
[15:26] <mamund> so steveklabnik, do you use the inline (FORM) pattern or the out-of-band (CODE) pattern (ala HAL)?
[15:27] <mamund> HAL, Atom both use the out-of-band defintion that clients must hard-code
[15:27] <mark_burns> do you have a link to hal? not sure what to search for
[15:27] <mamund> yeah
[15:27] <mamund> http://stateless.co/hal_specification.html
[15:28] <mark_burns> thanks
[15:28] <mamund> sure
[15:28] <mamund> i know HAL has both XML and JSON formats, not sure the status of the JSON one.
[15:28] <mamund> XML is registered w/ IANA, tho.
[15:29] <mark_burns> ok so hal only provides support for links?
[15:30] <mamund> yeah, like Atom/AtomPub, HAL expects clients to "know" what a valid paylod is ahead of time
[15:30] <mamund> my HTML expects clients to figure this out by looking at the response (inline)
[15:30] <mamund> my Collection+JSON uses an inline model like HTML
[15:30] <mamund> this is a design choice
[15:30] <mamund> VoiceXML uses inline, for example
[15:32] <mamund> this might also give you some context: http://www.amundsen.com/hypermedia/
[15:33] <mamund> and this: http://amundsen.com/hypermedia/hfactor/
[15:33] <mamund> of course, these are just inventions of mine to create names for common things already existing
[15:33] <steveklabnik> mamund: focusing on just xhtml support at the moment
[15:33] <mark_burns> ok i see. it seems like if (in the ruby world) there was a way to represent your resources as either HTML or Collection+JSON quite easily then it could be very useful for writing ruby or javascript clients
[15:34] <mamund> mark_burns: yes, that could make the _programmer_ experience easier
[15:34] <mamund> steveklabnik: xhtml, gotcha
[15:34] <mark_burns> mamund why the emphasis on programmer?
[15:35] <mamund> well, the message on the wire doesn't care _how_ it was created
[15:35] <mamund> neither does the server or client
[15:35] <mamund> a media type is the "message" passed between parties
[15:35] <mark_burns> well this is what i'm gradually starting to think about. all APIs require some level of human interaction
[15:35] <mark_burns> either out of band communication
[15:35] <mamund> if it's "hard" or "easy" to get a client or server to "do that" is not a big deal at runtime<g>
[15:35] <mark_burns> or exploration of an XHTML api
[15:36] <mamund> all APIs rely on humans
[15:36] <mark_burns> yeah sure. So it makes sense to make the part that humans have to do easy
[15:36] <mamund> either at the instant of execution (human intervention)
[15:36] <mark_burns> that's generally how i think as a rubyist
[15:36] <mamund> or at "build-time" (pre-planning)
[15:36] <mamund> that's cool
[15:36] <steveklabnik> mamund: just messing with ideas, not trying to be all-supporting
[15:36] <mamund> LOL
[15:37] <mamund> mark_burns: one big problem today is that no framework/coding environment does a good job of
[15:37] <mamund> making implementing "hypermedia-oriented designs" easy to do
[15:37] <mamund> it would be _waaaaay_ cool if that could happen
[15:37] <mark_burns> that's what i aim to tackle
[15:37] <mamund> yep
[15:38] <mamund> i suspect ruby esp. has an edge on most other frameworks in this area
[15:38] <mamund> as so much of it is about optimizing the programmer experience
[15:38] <steveklabnik> yeah.
[15:38] <mamund> it's a huge opp. i think
[15:38] <mamund> you guys are in the right place for this!
[15:38] <mamund> ruby-wise, i mean
[15:39] <steveklabnik> :)
[15:39] <steveklabnik> i'm trying to strike the balance
[15:39] <steveklabnik> between making 100% sure my book is good
[15:39] <steveklabnik> and missing this window i feel is happening
[15:39] <mark_burns> yeah. so how i imagine it is like this:
[15:39] <steveklabnik> trying to optimize for 'sooner and good enough' but it's difficult
[15:40] <mark_burns> my_business_process = Hateos.new 'api.example.com'
[15:40] <mark_burns> my_business_process.actions
[15:40] <mark_burns> #=> ['sign_in', 'sign_up]
[15:40] <mamund> steveklabnik: IMO, you gotta strike while the iron is hot, even if your aim or strength is a bit off
[15:40] <mamund> strike now, don't wait<g>
[15:40] <mark_burns> where the actions are dynamic
[15:40] <steveklabnik> totally.
[15:41] <mamund> mark_burns: my advice on this...
[15:41] <mamund> (the programming model for hypermedia that is...)
[15:41] <mamund> is to start from the point of the media type, not the events or objects.
[15:41] <mamund> start from the place where shared understanding happens
[15:41] <mamund> this is not yet done
[15:41] <mamund> may be too hard
[15:42] <mamund> but i think it's the right approach
[15:42] <mark_burns> well that's where the XHTML thing comes in i think
[15:42] <mamund> XHTML is just one media type
[15:42] <mark_burns> so my API consumes the human readable documentation
[15:42] <mamund> you can invent more; do new things in any format
[15:42] <mamund> but sure, if you want to start there, that's cool.
[15:43] <mark_burns> ok well i'm having enough of a brain melt getting my head around all these new ideas as it is
[15:43] <mamund> LOL
[15:43] <mamund> you're cool
[15:43] <steveklabnik> yeah, i think the 'makes it also human readable' is a great way to present value
[15:43] <steveklabnik> to rubyists
[15:43] <steveklabnik> and might get them away from their fear of xml ;)
[15:43] <mark_burns> what would a new format be?
[15:43] <mamund> wondering if that's the place to _start_ or the place to _end_ _up_
[15:43] <steveklabnik> i was thinking earlier about YAML with serealized Procs (lambdas) for code-on-demand purposes, too
[15:43] <steveklabnik> which would be interesting...
[15:44] <mamund> mark_burns: i once created a spec for hypermedia CSV
[15:44] <mamund> :)
[15:44] <trygvis> mamund: orly? did you document it anywhere?
[15:44] <mark_burns> mamund so what would you get from that, vs say JSON+collection or XHTML etc?
[15:46] <mamund> trygvis: nope, it's laying somewhere in the office, just an experiment really
[15:46] <mamund> mark_burns: not sure of your last Q, sorry. can you repeat w/ context?
[15:46] <trygvis> interresting. we're working with lots of csv data at the current client now
[15:46] <trygvis> mainly shuffling configuration data (big lists) between an admin server and portal servers
[15:47] <mamund> trygvis: i created an added document (also CSV) that described the transitions: a kind of FORMS for CSV
[15:47] <mamund> i'll dig it up and email you; might be entertaining<g>
[15:47] <trygvis> right now we're just reading xls files from disk and serving those, but I'd like to make an admin gui .. something like google spreadsheets
[15:47] <mamund> i was experimenting w/ hypermedia controls that appeared in a _separate_ document than the data.
[15:48] <trygvis> please do, I'd like to see your ideas
[15:48] <mamund> this would be interesting for CSV, RDF, etc.
[15:48] <mamund> LOL, no problem
[15:48] <mamund> might take the weekend to dig up and dust off, tho.
[15:48] <trygvis> np
[15:48] <mamund> :)
[15:48] <mamund> mark_burns: did i lose your thread? sorry.
[15:49] <mark_burns> mamund just trying to rephrase
[15:49] <mamund> np
[15:49] <mark_burns> i'm trying to get my head around what benefits a csv media type would give you
[15:49] <mamund> no formalities here; hack away<g>
[15:49] <mamund> ahhh
[15:49] <mark_burns> vs say xhtml
[15:49] <mamund> ok, that was really just an experiement
[15:50] <mamund> my idea was to see if you could express hypermedia in a secondary doc
[15:50] <mamund> also, could you provide clients w/ information on "next steps" on...
[15:50] <mamund> possible transitions
[15:50] <mamund> even when the format is "data-only" like CSV, RDF, "simple" JSON, etc.
[15:50] <trygvis> mark_burns: for me it would be a significant reduction in bandwidth and processing time
[15:50] <mamund> in the stuff i do...
[15:51] <mark_burns> in a more real world sense, would that be like a spreadsheet with links and forms?
[15:51] <mamund> mark_burns: it would be like "pure data" w/ forms attached.
[15:51] <mamund> i do work w/ clients that do lots of multi-tenant SaaS implementations.
[15:52] <mamund> each customer has special workflow, special fields, special screens, etc.
[15:52] <mamund> they accomodate this by using "hypermedia" in responses instead of "hard-coding" client apps
[15:52] <mamund> to know what to expect and what to do next.
[15:52] <mamund> does that make sense?
[15:53] <mamund> the more hypermedia in the response, the less custom code in the client
[15:53] <mamund> that's the POV for many of the clients i work w/
[15:53] <mamund> they make more profit if they don't have to recode<g>
[15:53] <mark_burns> yes. one thing that i think i understand more now is the idea of dynamic clients. you can't really get a truly dynamic client
[15:53] <mark_burns> like if you change the del attribute in a link
[15:53] <mark_burns> it breaks the client
[15:53] <mark_burns> if you change the business process you're describing
[15:53] <mark_burns> it breaks the client
[15:54] <mamund> yep - you see it
[15:54] <steveklabnik> a web browser is an incredibly dynamic client.
[15:54] <mark_burns> but you can at least not specify the exact urls etc
[15:54] <mark_burns> not _have to_ specifiy
[15:54] <mamund> so all this yammering about "hypermedia" is a way to try to quantify just what needs to show up in mesages in order to reduce the code in clients
[15:54] <mark_burns> but a web browser is only truly incredibly dynamic because of the human operating it
[15:55] <trygvis> hmhm, is there a registry of all registered HTTP headers?
[15:55] <trygvis> I keep on finding gold in existing RFCs, but it would be nice with an index
[15:55] <mamund> mark_burns: that particular hypermedia client is designed for a human driver
[15:55] <mamund> that's not the only way to do it
[15:55] <steveklabnik> mark_burns: i mean in the sense that it can handle an interface for many, many varied applications
[15:55] <mamund> HTML is a media type that is custom-built for that particular type of client, too.
[15:56] <mamund> that's not the only way to design a media type, either.
[15:56] <mark_burns> steveklabnik yeah sure. mamund so isn't designing a media type out-of-band communication?
[15:56] <mamund> yes
[15:56] <mamund> the media type is OOB.
[15:56] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[15:57] <mamund> that's why clients need to "code for the media type"
[15:57] <mamund> a meida type is _not_ an application domain
[15:57] <mamund> designing a media type is the most powerful way to share understanding between parties.
[15:57] <mark_burns> ok so the media type, and transitions (e.g. rel attributes) are the OOB stuff
[15:57] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Client Quit
[15:58] <mamund> it can be as generic (HTML) or as specific (my MAZE+XML type) as the design wishes
[15:58] <fu-manchu> trygvis: this? http://www.iana.org/assignments/message-headers/perm-headers.html
[15:58] <mamund> fu-manchu: good catch!
[15:59] <mamund> mark_burns: yep, transitions include links and forms (static and dynamic transtions)
[15:59] <whartung> For filing under "Media Types -- WTF": http://stackoverflow.com/questions/8144749/rest-api-versioning-when-using-atom-for-resource-collections/8145358#8145358
[15:59] <mamund> and there needs to be a way to "markup" (identify) data in responses.
[15:59] <mamund> whartung! you're alive!
[15:59] <mamund> :)
[15:59] <whartung> "It was the salmon mousse"
[16:00] <mamund> ewwwww
[16:00] <mamund> :)
[16:00] <mark_burns> steveklabnik so how would you picture 'marking-up' data in a good XHTML API?
[16:01] <steveklabnik> depends on what kind of data.
[16:01] <mamund> mark_burns, steveklabnik : have you seen "restfulie"?
[16:01] <whartung> I like to use <, >, and letters myself.
[16:01] <steveklabnik> yeah i have a patch in
[16:01] <steveklabnik> actually
[16:01] <steveklabnik> i forget why it made me not exactly like it
[16:01] <mamund> what do you think of the way they approach this hypermedia thing?
[16:01] <mamund> ahh
[16:02] <mamund> yeah
[16:02] <mamund> it had "legs" for a while, but seems to have stalled; not very popular, i think.
[16:02] <steveklabnik> re-reading the README, it seems pretty okay
[16:02] <steveklabnik> but a bit too focused on the details.
[16:02] <trygvis> fu-manchu: nice, thanks!
[16:02] <mamund> ahh
[16:02] <steveklabnik> especially given ruby's dynamic nature
[16:02] <steveklabnik> response = orders.link(payment).follow.post {creditcard => 4444}
[16:02] <mamund> i see
[16:03] <steveklabnik> should be more like response = orders.payment :creditcard => 4444
[16:03] <mamund> makes some sense (i don't code ruby, so my POV is a bit foggy)
[16:03] <mamund> so maybe some poor idioms?
[16:03] <steveklabnik> yeah.
[16:03] <mamund> understood
[16:04] <steveklabnik> it's certainly not _bad_
[16:04] <mamund> have you seen the .NET Web API stuff?
[16:04] <steveklabnik> but i'd like to enable people to abstract away the details.
[16:04] <mamund> steveklabnik: here's the trick...
[16:04] <steveklabnik> no, i stay the hell away from .NET. ;) I occasionally read stuff about it when it seems valuable, ie, MVP, for example
[16:04] <mamund> what are "details" to abstract away? and "details" to focus upon?
[16:04] <steveklabnik> or MVVM.
[16:05] <mamund> steveklabnik: i think they're attempt at doing HTTP well is worth a look.
[16:05] <mamund> i don't use it
[16:05] <steveklabnik> well, in the previous statement, that the transition is a link, and that we're following it.
[16:05] <mamund> but it's got merit, IMO>
[16:05] <steveklabnik> totally.
[16:05] <mamund> so, here's my sick mind at work....
[16:05] <steveklabnik> i also just don't have many connections to that world, so i dont hear a lot
[16:06] <mamund> from my POV, the "details" to focus upon...
[16:06] <mamund> are in the media type, no where else<g>.
[16:06] <mamund> i want to "code" in media type<g>
[16:06] <mark_burns> steveklabnik i did see that a while ago, but perhaps it was only java when i saw it.
[16:06] <mamund> i want a framework that "knows" the media type enough to allow me to simply...
[16:06] <steveklabnik> mark_burns: it's been in ruby for the last year or two at least
[16:06] <steveklabnik> mamund: hmmm.
[16:06] <mamund> mark up states and treansitions and "magic happens"
[16:07] <mark_burns> mamund what does '"code" in media type' mean?
[16:07] <steveklabnik> yeah, elaborate a bit
[16:07] <steveklabnik> my latency may increase as i'm going to start cooking dinner. i'll make sure to read backlog
[16:07] <mamund> consider that i'd want to return a list of "entities" to clients
[16:07] <mamund> i'd define that list as a "tremplate" for the media type
[16:08] <whartung> Media types aren't rich enough to "code" mamund, semantics aren't deep enough IMHO YMMV GTFO BBQ
[16:08] <mamund> i'd want certain transitions to appear in the response (they should be able to sarch, crate new entieis, select one, etc.)
[16:08] <mamund> whartung: sez you<g>
[16:08] <whartung> sez me
[16:08] <mamund> :)
[16:08] <whartung> entities != media type
[16:09] <mamund> zackly
[16:09] <mark_burns> steveklabnik anyway restfulie looks good. you're suggestion about the api improvements matches my idea too. i think i may co-opt some of restfulie in the hateoas stuff.
[16:09] <whartung> you can't safely model with media types either. Imho
[16:09] <mark_burns> i'm going to have to get off. it's getting late in the UK here. thanks for the interesting conversation and insights everyone
[16:09] <mamund> mark_burns: great to see you herer
[16:09] <mamund> hangout any time
[16:10] <mamund> lots of smart folks here
[16:10] <mamund> who'd love to hear about what you're doing
[16:10] <whartung> ..and me
[16:10] <mamund> ROFL
[16:10] <mark_burns> cool i'm sure i'll be back with more questions soon. thanks mamund and steveklabnik. haha.
[16:10] <mamund> have fun, no hacking!@
[16:10] mark_burns (~mark@cpc1-dals15-2-0-cust635.hari.cable.virginmedia.com) left #rest.
[16:11] <mamund> whartung: i still think that "coding in media type" is possible.
[16:11] <mamund> i know it's not right now
[16:11] <mamund> and it might even mean changing what a media type looks like in order to pull it off
[16:11] <mamund> but i think there is much more opp. there than we currently use
[16:12] <whartung> I guess it's a matter of definition of "coding". I associate coding with logic, not necessarily transcription (thought that's really more the legacy definition of "coding")
[16:12] <mamund> well, if you swallow the state machine pill, "logic" takes a diff form at the transfer protocl level.
[16:12] <mamund> i don't mean i want to code _servers_ using media types
[16:12] <whartung> What color is the state machine pill?
[16:12] <mamund> red, i assume<g>
[16:13] <mamund> might be blue
[16:13] <whartung> purple
[16:13] <mamund> LOL
[16:13] <mamund> i don't want to code _clients_ using media types
[16:13] <mamund> i want to code _apps_ using media types
[16:14] <mamund> just a pipe dream i have; one among many<g>
[16:14] <whartung> I mean, I can see sort of "wiring" use media types
[16:15] <whartung> using the SMP
[16:15] <steveklabnik> omg back
[16:15] <steveklabnik> re-reading history
[16:15] <mamund> ??
[16:15] <mamund> LOL
[16:15] <steveklabnik> also, mamund got a link to something about this .net rest stuff? which thing?
[16:15] <whartung> State Machine Pill
[16:16] <mamund> http://wcf.codeplex.com/wikipage?title=WCF%20HTTP
[16:16] <steveklabnik> thanks
[16:16] <steveklabnik> 'coding media types' still seems a bit vague
[16:17] <steveklabnik> ill just have to think about it for a while :)
[16:17] <mamund> yeah, i know it does
[16:17] <mamund> it _is_ vague
[16:17] <mamund> pretty diff way to think
[16:17] <mamund> not doing it right now myself
[16:17] <mamund> but doing so much of my work via the media type
[16:17] <mamund> it leads me to think that something like that is possible
[16:17] <whartung> well, I mean, all programing is shuffling of state.
[16:17] <mamund> we'll see
[16:18] <mamund> yep
[16:18] <whartung> media types lets you encode relationships and state transitions
[16:18] <mamund> for the last couple decades...
[16:18] <steveklabnik> whartung: NOT IN HASKELL
[16:18] <steveklabnik> ;)
[16:18] <mamund> the predominant model for source code has been to OO
[16:18] <whartung> Oh, it's still state steveklabnik..
[16:18] <mamund> for data, Relational
[16:19] <steveklabnik> whartung: damn, you see through my trolling
[16:19] <steveklabnik> MONADS MONADS MONDADS!
[16:19] <steveklabnik> :)
[16:19] <whartung> I'm an abstractionist -- I see over it :)
[16:19] <trygvis> haskell <3
[16:19] <trygvis> mamund: what did you use to author the collection+json pages?
[16:19] <mamund> now that we have netowrks of heterogenous, distant machinces
[16:19] <mamund> these mental models are not so useful.
[16:20] <mamund> tryg
[16:20] <whartung> they're still useful, but realities make the fine grained ones less pragmatic and practical
[16:20] <mamund> trygvis: LOL, i have an internal XML media type that gets transfoirmed into HTML
[16:20] <mamund> and i _stole_ a stylesheet from the W3C<g>
[16:20] <trygvis> you stole?! omg
[16:20] <mamund> lol
[16:20] <trygvis> you should just have *linked* it!
[16:21] <mamund> if you view-source those pages you'll see a full set of W3C styles
[16:21] <mamund> ok, i _forked_ it<g>
[16:22] <trygvis> erlend and I have been using pandoc2rfc a bit internally, but I like your style better
[16:22] <mamund> well, mine is a hack<g>
[16:23] <mamund> drifted over a couple years
[16:23] <mamund> XML format w/ XSLT to XHTML
[16:23] <mamund> the XML could come from DB, too. (did that once)
[16:24] <whartung> what are you writing your book in?
[16:24] <mamund> text was in XML docbook
[16:25] <mamund> considering asciidoc for next project, but not sure
[16:26] <steveklabnik> i'm using a variant of what Zed Shaw is using for his Learn Code The Hard Way books
[16:26] <steveklabnik> tl;dr: latex
[16:26] <mamund> yeah, not for me<g>
[16:26] <steveklabnik> :D
[16:26] <mamund> :)
[16:26] <trygvis> latex is too hard, lyx makes it very doable though
[16:26] <mamund> asciidoc is basically markdown that is processed into docbook
[16:27] <mamund> i like the idea of getting rid of the "ceremony" and just writing
[16:27] <whartung> yea I've played with asciidoc in the past
[16:27] <mamund> haven't done enough w/ the processor to know if it will do what i want, tho.
[16:27] <whartung> it produced reasonable results with zero effort
[16:27] <mamund> whartung: what did you tning?
[16:27] <mamund> think?
[16:29] <whartung> like I said, I spent 0 effort with it -- I just need something to pound out some documentation and I didn't want to use a word processor. I think it would be a great start for a pipeline, but I can't comment on extensibility or doing custom tweaks on "page 4 of chapter 3" kind of stuff.
[16:29] <mamund> yeah, will have to play around more to see if it works for me
[16:30] <whartung> I certainly didn't style it. And I know it was a little limited even for what I was doing, but some of those limitations might well be addressed if I actually read past the first 2 paragraphs of the "Getting started" documentation
[16:32] <mamund> LOL
[16:32] <whartung> But I could easily see that if I wanted to write a large treatise, like a book or something, I can see trying to do as much as I could in soething like that and saving the rest for cleanup and layout later, just so I wouldn't have to work with XML or pretty much anything else.
[16:33] <mamund> yeah, i use XmlMind editor and that works very well for docbook XML
[16:33] <mamund> just i was just looking for a new experience
[16:33] <mamund> something new to try
[16:33] <whartung> yea
[16:34] <mamund> LOL, i threatended to do my next project w/ asciidoc and vim!
[16:34] <whartung> that's probably what I did :)
[16:34] <whartung> I don't recall
[16:34] <mamund> LOL
[16:34] <whartung> sounds like something I would do
[16:34] <whartung> "vim has word wrap, what more do you want?
[16:34] <mamund> it'd be a good experience for me; frustrating at time, i suspect, but still good
[16:34] <steveklabnik> heh
[16:35] <whartung> I've always leaned toward the "RUNOFF" style of document markup. I've never warmed up to Word style WPs
[16:35] <mamund> big thing i need to learn is how to deal w/ images in asciidoc
[16:35] <mamund> hopefully that's not a big deal
[16:35] <whartung> (RUNOFF, boy that'll date me...)
[16:35] <mamund> TROFF
[16:35] <whartung> yea, I'm sure it has something. Whether it will be flexible enough I couldn't say
[16:36] <mamund> might find out soon<g>
[16:36] <mamund> ok, i need to book.
[16:36] <mamund> late here for me and dinner i calling me
[16:36] mamund grabs his stuff and heads out the door
[16:37] <whartung> tt mamund
[17:24] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[17:45] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[18:46] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[19:09] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) left irc: Read error: Operation timed out
[19:16] sbanwart (~sbanwart@99.177.126.136) joined #rest.
[19:24] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) joined #rest.
[19:29] KevBurnsJr (~KevBurnsJ@50.0.103.39) left irc: Quit: were done.
[19:36] bigbluehat (~bigblueha@adsl-98-71-180-108.gsp.bellsouth.net) joined #rest.
[19:40] bigbluehat (~bigblueha@adsl-98-71-180-108.gsp.bellsouth.net) left irc: Ping timeout: 260 seconds
[20:01] sbanwart (~sbanwart@99.177.126.136) left irc: Ping timeout: 248 seconds
[21:05] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[21:24] omarkj (u766@gateway/web/irccloud.com/x-fwocryullgvsipbh) left irc: Excess Flood
[21:24] omarkj (u766@gateway/web/irccloud.com/x-xweivxrkcuptsfjf) joined #rest.
[21:29] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[21:31] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Client Quit
[22:11] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[23:47] tomayac_ (~tomayac@213.61.101.1) joined #rest.
[00:00] --- Fri Nov 18 2011