Thanks Dan, and others. These responses are along the lines of what I'd expected. And sufficient to inspire me to find some time at least to bring a sample Scala app up using some River mechanisms. I'd like to put a few samples and a presentation together for a future pdxscala meeting.
On Sat, Oct 22, 2011 at 12:27 AM, Dan Creswell <[email protected]> wrote: > > (1) The programming [Jini, Akka] models are substantially different... I agree there is a fascination with Actor-ish models in Scala and the industry in general. One path of introducing Jini to the Scala community could begin with Javaspaces and Workers, which are similar enough to attract attention. That may lead some to explore more of the breadth of a spaces model. > ...people still want the snake oil... (I think for various > other reasons that will always be the case, another story > there). Probably so. If there is a lot of interest in Akka and actors and perhaps ten percent of those developers might be attracted to Jini, that still could be enough to move Jini and River forward. > Doug Lea has some interesting stuff to say on transactional > memory, actors and such here: > http://days2011.scala-lang.org/node/138/274 - I'd summarise > as "horses for courses and no silver bullet". Watch it though, > it's a great talk. Nice. Thanks. > Whilst most hold that introducing asynchronous operation is > sufficient to paper over the cracks of local vs remote, it's > not true. One must also account for lost messages which means > introducing timeouts. Note that messages aren't lost in the > local model but will be across networks requiring resends. That > introduces highly variable latency where on networks with no > problems, things are fine as they are on the local box but not > for the failing network. Yeah, I think I've come around to this. Erlang's message passing for local and remote processes had appealed to me, even with the awareness of the differences. I'm not sure about that now. Scala's features for writing in an applicative style, using functional data structures combined with the underlying Java concurrency mechanisms seem better for "local", and then deliberately programming with the network in mind for "remote". Thanks -Patrick
