On Fri, Oct 18, 2013 at 12:23 PM, Noah Watkins <noah.watkins@xxxxxxxxxxx> wrote: > On Fri, Oct 18, 2013 at 12:04 PM, <Paul_Whittington@xxxxxxxxxx> wrote: >> Hi all, >> >> Is this possible? >> Does it make sense? > > As far as constructing scriptable object interfaces (Java, LISP, > etc...) this is certainly possible, and pretty cool :) Currently we > have a development version of Lua support (github.com/ceph/ceph.git > cls-lua), and an LLVM JIT implementation about ready to make public. This definitely makes sense, but I think the rest of it might be stretching the abstraction and capabilities a bit farther than they're prepared for. Object class methods right now are synchronous calls — the client sends in an op on object foo, the op is executed on object foo (including the call into the object class), and then it returns to the client. While it's processing that op, other accesses to object foo are blocked. While we are starting to equip the OSDs with the tooling necessary to spin off operations to other objects on other OSDs as part of our promote work, it's still fairly primitive and there's no direct exposure to it via the object classes — and again, these sorts of subops within a class would block anybody else wanting to access that object. What I suspect you could do feasibly is embed object classes which do each stage of a pipeline in the smallest granularity that's feasible, and then have intelligent clients sending off the op requests and marshaling responses as appropriate. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |