Interesting, Larry. What IP protocol does your communication mechanism use? HTTP, or raw IP? If HTTP, how do you handle it?
I thought of using a simple web service as well, by incorporating one of the numerous simple OSS Java HTTP server classes which are around. (I guess you'd need a client too - maybe some of them are symmetrical 8^). Then you could use XML or even just Java serialization as the language. Of course, you are basically just reinventing RMI - but maybe slightly simpler. One slight downside of RMI is that you need to run the rmiregistry app as well, and you also need to set appropriate JVM policies. This is all fairly easy to do, but it does add complexity and more points of failure. The advantage of using Java serialization for the protocol is that it's size-efficient, and eliminates any parsing Disadvantage is Java only... I did a small experiment exposing some JTS functions as RMI methods, and it worked like a charm. So RMI is quite viable for doing this. I'm thinking of adding this to the JTS TestBuilder to allow it to function as a "spatial logger". But this is a low-priority project for me right now... Martin Larry Becker wrote: > Hi Martin, > > I'm still thinking about your RMI idea. In SkyJUMP, there is a > communications module that allows other programs to control it remotely. It > doesn't use RMI, but it could be ported to OJ and changed to do so. It > includes two bidirectional channels for command and data. The protocol is > XML and the module allows arbitrary execution of plugins. An example is: > > <?xml version="1.0" encoding="UTF-8"?> > <command-data> > <command>SendDatasetPlugIn</command> > <parameters> > <properties> > <mapping> > <key class="java.lang.String">input-filename</key> > <value class="java.lang.String">C:\JUMP\tmp\test.jml</value> > </mapping> > </properties> > </parameters> > </command-data> > > This example causes the current selection to be written to the designated > file. Just thought I would keep the ball rolling on this idea. > > regards, > Larry > > On Thu, Jun 3, 2010 at 2:39 PM, Martin Davis <mbda...@refractions.net>wrote: > > >> It occurred to me recently that it might be useful to have a spatial >> viewer acting as an RMI service for out-of-process or remote clients. A >> possible use case would be as a "spatial logger" - a client process >> could log spatial data generated during the course of execution which >> would be immediately viewable in the spatial viewer. The neat thing is >> that this would work during a debug session, so the developer could get >> a good view of data being processed during the run. >> >> For those not familiar with it, RMI makes it almost trivially easy to >> expose a service endpoint and communicate with it from other Java >> processes. It would be fairly simple to expose a service that allowed >> clients to create layers, add features to layers, etc. Really the >> service could expose almost anything that can be manipulated in JUMP). >> It would thus enable a sort of "remote plugin" facility. I also >> envision a very simple client API that hid the (fairly trivial) aspects >> of connecting to an RMI service. >> >> This may be a solution in search of a problem - but RMI is so powerful >> it seems like there must be some applications for it. >> >> Has anyone played around with exposing an RMI service from JUMP? >> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ------------------------------------------------------------------------ > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
