Re: Resource factories

[Tal Liron]

Thanks, Rob! I value your gut instinct in this. Perhaps, then, we can indeed move this over the code review side. Specifically, I would be very happy if you and others could take a look at the script extension I am working on in Restlet svn. It has two Resource-based classes that currently rely on a few static fields to configure some high-level stuff. This is not a problem as long as we are dealing with a single use of these classes, or multiple uses where we don't mind sharing the configuration details. I suspect that this is good enough for many use-cases, but I can also imagine situations where this would be a problem. (Anybody: feel free to answer on the code mailing list. I started the discussion here because I feel this issue could impacts many users of Restlet, not just this specific contribution.) -Tal Rob Heittman wrote: In addition to what Rhett said ... one massively huge benefit of having Resources that are created per-request is that they need not be thread safe. Very few developers (:: cough :: except Tim) can do concurrency correctly every time. But I've spent most of the afternoon noodling over this discussion and wondering why the Resource construction issue has never really bugged me like it bugs Tal. I guess I just have never written Resources that have a lot of of local configuration state. This might be because I'm not an IoC/DI guy by default -- it's a tool I use sometimes, but not a fundamental way of thinking for me. It may also help to know that I tend to like functional programming a lot, and tend to avoid static fields in general; I fear the bite of class loader hierarchies I didn't expect. For the higher-level configuration stuff, I tend to dynamically fetch it from the Application itself (which of course is wired-in and long-lived) or the Context. Really, this isn't noticeably costly. I'm not in opposition to more ways of constructing a Resource. But I also feel, somewhere in my bones, that if Resources really chafe at the existing model, they /probably/ can be refactored or redesigned to be a much smoother fit, without losing anything important ... but just thinking differently. I would be willing to have a look at a concrete case -- e.g. a resource in the scripting extension -- and try to make a proposal if one fits. Then we could talk about it in code review specifics and not in general architectural chalk talk. - R On Mon, Mar 23, 2009 at 4:08 PM, David Bordoley <bordo...@gmail.com> wrote: Out of curiosity is there a reason why Resource isn't implemented as a subclass of Restlet? It seams like there is a lot of overhead in initializing a new Resource on every request especially when a lot of salient features such as what methods,variants, etc that are supported tend to static for a give route to that resource. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1394971