On 5 May 2011, at 03:18, Galder Zamarreño wrote: > Vladimir, from a HotRod protocol perspective we'd need a new operation but > after that the body, as Manik suggested, you could have javascript which the > HotRod server ignores and passes it to the distexec code which deals with it > accordingly. Can't we just handle this through a interceptor rather than adding a operation? > > I was wondering too whether we'd need streaming here or not but at first > glance it does not appear to be as important as in remote querying. > > On May 4, 2011, at 11:51 PM, Manik Surtani wrote: > >> Well, I feel exposing M/R over Hot Rod - from a protocol standpoint - would >> require a platform-independent mechanism of defining a closure (keeping in >> mind we need to allow this from non-Java clients too). >> >> So I reckon Javascript is the way to go, at least from a protocol >> standpoint. Now how we expose this in remote client APIs (Java, Python, >> etc) needs some thought, but at first glance it would seem as though we >> won't have a direct mapping to what we do on the embedded side of things. >> E.g., http://www.mongodb.org/display/DOCS/MapReduce >> >> - Manik >> >> On 4 May 2011, at 04:50, Vladimir Blagojevic wrote: >> >>> Galder, >>> >>> I believe the ability to invoke distributed executors and mapreduce over >>> hotrod would be very interesting. However, I quickly realized that >>> internals of both DistributedExecutorService and MapReduceTask rely >>> heavily on some Cache internals (RpcManager, CommandsFactory, >>> InterceptoChain) that are only available in non-remote caches. There is >>> no way to fake this by simply passing RemoteCache instead of Cache. >>> Either we rethink the internals of DistributedExecutorService and >>> MapReduceTask or we somehow bridge to these abstractions from a thin >>> client. >>> >>> Any thoughts how we could potentially achieve hotrodization of dist. exec? >>> >>> Regards, >>> Vladimir >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> ma...@jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
