[00:03:13] jaminja (~jaminja@76.76.24.43) joined #rest. [00:03:13] jaminja (~jaminja@76.76.24.43) left irc: Changing host [00:03:13] jaminja (~jaminja@unaffiliated/jaminja) joined #rest. [00:15:35] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [01:06:40] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) joined #rest. [02:06:54] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 244 seconds [02:16:02] jaminja (~jaminja@unaffiliated/jaminja) joined #rest. [02:36:39] row (~row@188.21.76.42) left #rest. [04:19:03] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 252 seconds [04:27:38] steveklabnik (steve@nat/xomb/x-dcpntzhekbsoibnx) joined #rest. [04:27:43] jaminja (~jaminja@unaffiliated/jaminja) joined #rest. [05:03:04] bigbluehat (~bigblueha@68-115-173-74.static.ahvl.nc.charter.com) joined #rest. [05:24:38] bushwakko (~bushwakko@fou170.telenor.ntnu.no) joined #rest. [05:24:53] I'm trying to inject something tagged with @Provider in jersey by Using @Context, however I see that a type is returned from the Provider, but it's null after the @Context annotation: "Returning instance of defaultInstance com.telenor.sw.sylfide.server.Config@3a396fce" and then later "Config is null" [05:50:44] It works if I inject into a method [05:53:28] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) left irc: Quit: Leaving... [06:20:36] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [06:36:21] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [06:41:24] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [06:47:11] grove_ (~grove@193.201.9.46.customer.cdi.no) joined #rest. [06:49:15] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [06:50:05] grove (~grove@aggw006.cappelendamm.no) left irc: Ping timeout: 260 seconds [06:50:06] Nick change: grove_ -> grove [06:56:51] jaminja (~jaminja@unaffiliated/jaminja) left irc: Read error: Operation timed out [06:57:49] bigbluehat (~bigblueha@68-115-173-74.static.ahvl.nc.charter.com) left irc: Quit: Leaving. [07:11:33] bushwakko (~bushwakko@fou170.telenor.ntnu.no) left irc: Quit: bushwakko [07:26:50] Hakon|mbp (~hakon1@38-227-11.connect.netcom.no) joined #rest. [07:58:23] ramsey (~ramsey@unaffiliated/ramsey) left irc: Excess Flood [07:59:20] ramsey (~ramsey@unaffiliated/ramsey) joined #rest. [08:06:03] nkoza (~NKoza@190.244.122.9) joined #rest. [08:12:14] Hakon|mbp (~hakon1@38-227-11.connect.netcom.no) left irc: Ping timeout: 260 seconds [08:12:14] NOKAH (~hakon1@83-244-232.connect.netcom.no) joined #rest. [08:12:49] nkoza (~NKoza@190.244.122.9) left irc: Quit: Client exiting [08:20:25] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest. [08:22:23] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [08:40:01] NOKAH (~hakon1@83-244-232.connect.netcom.no) left irc: Read error: Connection reset by peer [08:49:19] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [09:36:04] Morning all [09:41:51] bigbluehat (~bigblueha@adsl-98-71-134-245.gsp.bellsouth.net) joined #rest. [10:41:16] nkoza (~NKoza@190.244.122.9) joined #rest. [10:46:08] versatiletech (~versatile@187.146.88.184.cfl.res.rr.com) joined #rest. [10:54:14] ivanfi (~ivanfi@62.159.77.166) left irc: Quit: Leaving. [11:24:04] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest. [11:26:22] if I have a resource that represents a user's profile (first name, last name, email) and I want a client to just be able to update just the first name would I have to a create a new subordinate "first-name" resource for it to stay restful? For instance PUT /users/1234/first-name? Or could I have a subordination "profile" PUT /users/1234/profile and send a request body that represents the resource partially, not the complete resource, f [11:26:22] the purpose of just updating the first name in profile? [11:27:51] you could look in to PATCH to do partial updates of the single, master resource [11:32:02] I find having the subordinate resource is usually a good thing, because I can set a reasonable cache timeout on the parent resource, and a no-cache on the child. That seems to fit the workflow of most clients: they either want to just read the whole thing, and are comfortable with values that are slightly stale, or they want to read-and-then-update one value, in which case they can use the child for both. [11:33:18] (at least in my last few apps; Your Access Patterns May Vary) [11:48:48] whartung: I'll see if the framework I'm using will allow PATCH [11:50:34] fumanchu: so are you suggesting something like a subordinate resource of "first-name" instead of "profile" for a partial update? [11:51:03] whichever works better for the client; I've done both [11:51:49] the other detail, is whether the proxies support PATCH properly and invalidate the resource -- they should but I don't know. [11:52:04] the Shoji media type I developed calls the "profile" pattern a "fragment" and calls the "first-name" pattern a "value" [11:52:07] www.aminus.org/rbre/shoji/shoji-draft-02.txt [11:58:18] whartung: do you mean that when using PATCH should invalidate the original cached resource so that the client gets the updated resource? If so, wouldn't it be the responsibility of the server to invalidate the original cached resource? [12:04:03] versatiletech: The point is to ensure that any intervening proxies invalidate it as well. They SHOULD, but PATCH may be less supported than PUT or POST. [12:06:30] whartung: sorry for my naiveness, but could you explain what you mean by proxies? [12:06:41] mephju (~mephju@dslb-094-222-019-203.pools.arcor-ip.net) joined #rest. [12:07:32] Hakon|mbp (~hakon1@155-214-232.connect.netcom.no) joined #rest. [12:07:39] many times there is a proxy between your ulitimate client and the actual server. Like, say, in a company. client -> proxy -> your_server [12:07:56] the proxies will cache resources according to the HTTP spec (or not...) [12:08:13] so, for example, if your server is the single source for a resrouce [12:09:01] so a proxy will cache a resource from your server and respond directly to the client, without involving you. [12:09:22] oh [12:09:37] but if someone does a PUT / POST / PATCH (ideally) THROUGH the proxy, the proxy know to invalidate it's current copy, REGARDLESS of the caching parameters [12:10:38] so if you say your stuff is "good for 5 minutes" someone working directly on the resrouce, would invalidate it through THEIR proxy, and that proxy would continually fetch fresh updates. While other proxies would cache the resrouce for 5 minutes. After 5 minutes, they'd get a new copy. [12:10:44] oh! I see what you mean. [12:12:39] so what I can not attest to is how widely and well supported PATCH is in regards to such proxies out in the wild. I simply don't know. And the rate of that adoption might be a consideration for your on choosing PATCH as an option, it depends on your use case. [12:13:26] hmm, but that is really dependent on the proxy supporting PATCH. PATCH is pretty new right? So I could expect some proxies invalidating resources and others not. Are there any workarounds for this? Maybe putting in the documentation that clients should be weary of their proxy not invalidating resources when using PATCH. [12:13:34] beat me to it [12:13:35] hehe [12:14:20] by documentation, I mean my developer documentation for the REST API [12:15:15] Hakon|mbp (~hakon1@155-214-232.connect.netcom.no) left irc: Ping timeout: 260 seconds [12:16:12] whartung: thanks for the explanation. Now I get it ;). [12:29:12] nkoza (~NKoza@190.244.122.9) left irc: Quit: Client exiting [12:34:49] mephju (~mephju@dslb-094-222-019-203.pools.arcor-ip.net) left irc: Read error: Connection reset by peer [13:25:51] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Quit: bradley-holt [13:53:49] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [13:59:05] bigbluehat (~bigblueha@adsl-98-71-134-245.gsp.bellsouth.net) left irc: Quit: Leaving. [14:19:01] DracoBlue (~Adium@109-226-148-38.cable.swschwedt.net) joined #rest. [14:19:18] DracoBlue (~Adium@109-226-148-38.cable.swschwedt.net) left #rest. [14:22:40] how can AtomPub be used instead of WebDAV? [14:26:17] I guess a feed is equivalent to a folder and the media element entries are files. [14:26:45] Not really a hierarchial file system though. [14:26:52] ye ak [14:28:49] I was thinking of working on a image server. Something that will accept images and serve them up. Notably it would be able to (possibly -- haven't though it completely trhough) convert format (i.e. jpg to png) but also do automatic resizing. [14:29:25] I was debating having some de-duping logic in it [14:29:50] (if a file has the same size and hash as another, then just return the original reference to it) [14:30:47] and then the question came in my head (itty bitty thing that it is) whether those should be separate services, especially the resize and format change, since we'll only want to do those operations once unless the original changes. [14:31:07] and whether a "hand crafted" protocol would work or web dav or waht. [14:33:09] ramsey (~ramsey@unaffiliated/ramsey) left irc: Remote host closed the connection [14:33:37] yeah, I'd be reluctant to use web dev personally considering the types of transformations that you are looking at doing. [14:33:54] s/web dev/web dav [14:33:55] just trying to not reinvent the wheel [14:34:12] well, web devs are dangerous as well...I try to stay clear of them too [14:34:14] yeah. [14:34:19] +1 [14:34:24] :) [14:35:17] I collegue of mine did a similar kind of image server. It makes sense. [14:38:32] GET /image.png?width=100 [14:40:17] I would think that the deriviative resources (like this width=100 one) would return the same Last-Modified and Etag as the original. [14:40:51] seems reasonable [14:57:18] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [15:03:26] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [15:21:10] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest. [15:25:26] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove [15:31:20] versatiletech (~versatile@187.146.88.184.cfl.res.rr.com) left irc: Quit: versatiletech [16:44:14] Nick change: scott- -> _scott [17:18:48] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Read error: Operation timed out [17:27:45] KevBurnsJr (~KevBurnsJ@50.0.103.39) left irc: [17:41:32] bigbluehat (~bigblueha@adsl-98-71-134-245.gsp.bellsouth.net) joined #rest. [17:41:53] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest. [17:45:49] bigbluehat (~bigblueha@adsl-98-71-134-245.gsp.bellsouth.net) left irc: Client Quit [18:48:34] jaminja (~jaminja@76.76.24.43) joined #rest. [18:48:34] jaminja (~jaminja@76.76.24.43) left irc: Changing host [18:48:34] jaminja (~jaminja@unaffiliated/jaminja) joined #rest. [18:57:07] KevBurnsJr (~kevburnsj@c-67-169-94-104.hsd1.ca.comcast.net) joined #rest. [19:23:23] jaminja (~jaminja@unaffiliated/jaminja) left irc: Ping timeout: 260 seconds [19:43:49] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 252 seconds [20:05:06] KevBurnsJr (~kevburnsj@c-67-169-94-104.hsd1.ca.comcast.net) left irc: Ping timeout: 256 seconds [20:33:02] versatiletech (~versatile@187.146.88.184.cfl.res.rr.com) joined #rest. [20:33:55] versatiletech (~versatile@187.146.88.184.cfl.res.rr.com) left irc: Client Quit [20:48:52] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Computer has gone to sleep. [22:17:03] speaking about URL representations: would /image.png/widths/100 be appropriate [22:17:19] (my concern would be caching here) [22:17:33] or maybe just image_100.png, hmm.. [23:46:44] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest. [00:00:00] --- Sat Oct 29 2011