I can't say I've explored it at all, certainly not beyond thinking "wouldn't be interesting if I could..."
Certainly the methods you describe would probably work, I just need to find the time to experiment. Cheers, Tom Grammar and spelling have been sacrificed on the altar of messaging via mobile device. On 22 Jun 2011 16:59, "Greg Trasuk" <[email protected]> wrote: > > On Wed, 2011-06-22 at 04:38, Tom Hobbs wrote: >> Hi Oliver, >> >> actually, I think you've picked up on something very interesting. It's >> something that I've been kicking around in my head for a while. I have more >> general ideas though. >> >> One of the things I've used javaspaces for has been to contain discrete >> items if work that are then picked up by workers for execution, a standard >> pattern for sure. I think that there's mileage in modifying that pattern so >> the implementation of the workers is bundled into the entry of the space. >> > > Entries can contain objects, yes? Couldn't that object have a method > called execute() or something similar? Then you could have generic > workers that simply wait for an entry and call the execute() method on a > contained object. > > For that matter, there is a mechanism to register a listener on the > Javaspace. Is there any reason why such a listener has to be an > exported proxy to a remote listener? Couldn't it be just an instance of > some class that implements the notify() method, but then does something > locally on the space? > > Cheers, > > Greg. > >> That looks a little like a distributed Executor to me. Would you be >> interested in putting together a Jira issue to track this as a River >> enhancement? >> >> Cheers, >> >> Tom >> >> Grammar and spelling have been sacrificed on the altar of messaging via >> mobile device. >> >> On 19 Jun 2011 13:18, "Gregg Wonderly" <[email protected]> wrote: >> > The work I did on my griddle.dev.java.net project was to allow this kind >> of thing to happen. >> > >> > With griddle, data and keys are separated and comparison is programmable. >> There is iterator and executor support on the server side, with executors >> just returning an iterator. >> > >> > It was just some exploratory work, but it dis function in the testing I >> did with it. It probably is not packed in a way for production use, yet. >> > >> > Gregg Wonderly >> > >> > Sent from my iPhone >> > >> > On Jun 18, 2011, at 4:39 AM, Oliver Plohmann <[email protected]> >> wrote: >> > >> >> Hello, >> >> >> >> the idea of Linda tuple spaces is to have a passive central space where >> clients can add or remove data. The client cannot invoke any server-side >> execution. This programming model is very well suited for a wide range of >> applications. But I'm asking myself whether it would make sense to allow for >> some server-side execution for certain exceptional cases where this makes >> sense. I guess this is some kind of perennial discussion ... >> >> >> >> Let's give an example. Lately, I was prototyping a a little stm >> framework. After a while I asked myself how to implement the commit of a >> transaction. Well, you change some atomic variable for all affected data in >> the transaction and then the new values become visible at once. Then I asked >> myself how you would implement that when developing a distributed stm system >> using JavaSpaces. The easiest way would be to send the change list of the >> transaction to the server and execute the code on the server-side to process >> the changes and change the atomic variable when doing the commit. But this >> cannot be done, because there is no way to spawn some server-side thread in >> JavaSpaces. Then, I have to do the commit on the client-side. This will >> necessarily result in a lot more traffic between the client and the central >> tuple space. >> >> >> >> Now someone might say, that GigaSpaces or whatever system supports >> optimistic locking and therefore to implement a distributed stm system with >> GigaSpaces or whatever would be no problem. The point is here that a >> distributed stm system is only an example of why server-side execution might >> be justified in certain circumstances. You can find other examples for >> things for which some JavaSpaces implementation has no direct support and >> you are confronted with the same question whether there should be an option >> to do some server-side execution in JavaSpaces. >> >> >> >> So my point is merely "philosophical". If I were the owner of JavaSpaces >> I would try to make sure that the clean and elegant programming model of >> Linda tuple spaces won't fall apart and let things remain the way they are. >> But the question whether some server-side execution makes sense still >> bothers me. What do you think? >> >> >> >> Regards, Oliver >> >> >> >> >> >> www.objectscape.org >> >> >
