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

On 4 May 2011, at 23:47, Tristan Tarrant wrote: > On Wed, May 4, 2011 at 23:51, Manik Surtani <manik(a)jboss.org&gt; wrote: > > 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 > > Actually, using javax.script, we could default to Javascript (which is included in every Java6 implementation out there) but also be able to specify alternatives via a mimetype. In this way one could use any of the JSR 223 languages (Jython, JRuby, Groovy, etc). This is a pretty good idea I think. _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 9 May 2011, at 16:53, Galder Zamarreño wrote: > I've created https://issues.jboss.org/browse/ISPN-1094 Great. So I know this is a way off (maybe Infinispan 5.2 or 6?) but does someone want to "own" it for now, maintain a design wiki page to capture ideas and thoughts, link to the JIRA? Tristan's JSR-233 suggestion could be very valid, and I spoke to Sanne about this offline at JBW as well and he had some interesting thoughts to contribute. So - any takers? :-) -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I would like to co-lead this effort with Mircea. Having two of us on it would be perfect I believe.

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> manik(a)jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev