Hi, No URL yet, it's in a design phase now. It's an experiment on replacing sequences with reducers where possible and one of its part is a reducible I/O. I've said complected because I like to separate the resource itself from e.g. the way it is accessed (async or blocking). If your defapi is a composition of some more primitive functionality, I would like to brainstorm these first.
Resources which are not readable of course do not implement CollReduce. So far the only fn guaranteed to be implemented by every resource is uri, which returns resource's URI. Most resources are Openable, and opened resources can be further reducible (can be read from) and/or drainable (consumes a reducible coll). JW On Thursday, October 3, 2013 3:10:36 AM UTC+2, Mikera wrote: > > Hi Jozef, > > Sounds interesting - is it open source / can you give a URL? > > Design question: Why are you interpreting resources as a reducible? I can > see that making sense for some resources, but not for others..... > > As for "complected" - be careful not to confuse this with "composed". It's > perfectly reasonable to create higher order functionality by composing > simpler components (which is what I am proposing in this case). > > On Tuesday, 1 October 2013 15:50:53 UTC+8, Jozef Wagner wrote: >> >> Hi, >> >> Your approach seems very complected to me. What I'm currently working on >> is the following concept: >> A resource type, which can be a file, url, some remote REST/SOAP resource >> or e.g. a kestrel queue. Each resource has URI and can be used in following >> ways: >> - as a regular reducible collection: resource is opened when reduce/fold >> starts and closed after reduce is finished. >> - as a normal function: opens resource, sends data, then returns the >> response as an above reducible. >> - in an asynchronous way, in which case the 'async open' function returns >> two channels, one for input and other for output. closed when you close the >> output channel. >> >> It provides all features you've mentioned. API in that case will be just >> a collection of such resources. You can put them in a map, namespace, or >> serialize them. >> >> Data format which is sent/recieved is resource-specific, but it is often >> a byte collection. You can apply formatter on a resource that translate >> between data formats (e.g. utf-8<->char, json<->clj-objects) >> >> JW >> >> >> On Tue, Oct 1, 2013 at 5:46 AM, Mikera <mike.r.an...@gmail.com> wrote: >> >>> Hi all, >>> >>> I'm curious about the options for managing APIs in Clojure code in a >>> relatively idiomatic / consistent / functional way. The features I'm >>> roughly interested in are: >>> - ability to "wrap" a remote API in a regular Clojure function >>> - abstraction away from the details of how the API is implemented (REST, >>> SOAP etc.) >>> - sane handling for both async and synchronous calls (ideally building >>> on core.async) >>> - possible serialisation of API references (e.g. you can send an API >>> function to another machine that can then call it) >>> - sane default handling for standard stuff like timeouts, errors etc? >>> >>> I'm thinking of syntax roughly like: >>> >>> (defapi foo >>> :call (fn [x] (do-rest-call "http://some.host/api/foo"; x other-param)) >>> :timeout 1000 >>> :async true >>> :on-error (fn [ex] (handle-exception ex))) >>> => [an API object, probably a defrecord-like structure that implements >>> IFn] >>> >>> (foo "hello") >>> => core.asyc channel that returns result of calling foo API >>> >>> ((sync foo) "hello") >>> => result of synchronously calling foo API >>> >>> (async? foo) >>> => true >>> >>> ((modify foo {:timeout 100}) "quick hello") >>> => like (foo "hello") but with a shorter timeout >>> >>> >>> Has anyone built or seen anything like this? >>> If not, would this be a useful library / contrib? >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- -- 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.
