On 16 November 2013 19:46, Marcin Skotniczny <cosmi.co...@gmail.com> wrote:
> > Doesn't this approach risk unnecessary repetition? >> >> I am not sure if I catch your drift... What I wanted to have is a direct > replacement for clojure.java.io/resource function - so if at some layer > you come down to using this function, you can just replace it with cornet > generated handler -> the function signature (accepted arguments and > returned value) is the same. I could use ring-spec or something similar, > but I think this is simpler, IMHO more elegant and (I think) a bit more > flexible. > That does make a lot of sense, and I admit I'm in two minds about whether this isn't a better solution than basing it on Ring's architecture. I think the key (perhaps only) advantage of using a request/response map has is that you can provide more caching information via headers. This means you can loosely couple the caching architecture from the actual generation of your resources. (And by caching, I include the general case of storing the compiled CSS and JS files.) Without this, caching needs to be more tightly coupled, but perhaps this isn't necessarily huge disadvantage. Incidentally, I was planning on introducing the following basic caching protocol in a ring-cache library: (defprotocol Cache (store! [cache key value]) (retrieve [cache key])) I'm not certain if this would be useful for you to support, or whether all your caching of compiled assets is going to be purely on the filesystem. Basing on most typical real-life usage, the only need for recompilation is > during development, so I guess performance here is not important. The cache > in Cornet is dynamic (that is: tracks when source file changes) only in > development mode - so if you have some assets that change _during_ app > uptime on production server, then the basic Cornet stack is not suitable > for your needs (although in this case I think that development mode will be > fast enough - tracking changes is based on single .lastModified queries). > What about a case where you want to store the production files on some external CDN? I guess that could be considered as part of the deployment process, done separately through some additional script. But by keeping it all "in-house", one could generate URLs that would work for both development and production purposes. > Otherwise, Cornet will return file urls, so you can check their timestamp > and return 304, just like you would with normal files. The problem I had > with caching on higher layer is that it is tricky to track the original > file if you have many transformations pipelined - especially if some of > them can combine multiple files. > > >> If someone writes some caching middleware, or middleware that optimises >> Javascript, or whatever else, it's not compatible with the new abstraction >> you've introduced. >> >> > Well, you can just write middleware that is compatibile with it :). > Anyway, it shouldn't be difficult to create an adapter to ring-spec or > whatever format the middleware would use, right? > That's certainly true, it just feels a little iffy :) Overall, Cornet looks to be a big step forward. I suspect our only point of contention is on the architecture around storing the compiled data, and even then I'm uncertain whether you don't have the best approach after all. - James -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
