This is an architecture question. I am running Jeodes JVM on a PDA and am quite impressed with RMI and the capabilities of Java! In particular if a remote device is disconnected due to a network outage then just serialize your work to a file and when the networks back up, pump the calls back through. Callbacks work great as well. Once this is set up you really can do some very fluid distributed apps!! Not to mention the server side will run everywhere! (unlike some other, ahem language) ok, heres the design issue. I am now performing real time video and fingerprint capture. (Which works great as well) The code is written in C++, the Java app is using AWT. The C++ code is using native window calls which would interfere with the display of the AWT. I see 3 possibilities 1) Push the video and FP calls into a DLL complete with a "primative" windows initialization and use JNI. Then let the AWT refresh over the native calls with some of the graphics primitives. (messy) 2) Have 2 programs one is C++ using window calls. The other uses some sort of queueing method to push and pull the data into an RMI client program. The RMI client program then makes all of the distributed processing calls. The question here is there a prebuilt queueing service to use or should I roll my own? (File?) 3) Have 2 programs, the first in C++ using window calls. The other uses TCP or UDP to provide IPC to the push and pull the data from the windows program into an RMI client program. The RMI program then makes all of the distributed processing calls. believe it or not this is a hoot of a project, doing biometics and security identification using mobile devices.
Yup, yup, yup. Tiny ad:
how do I do my own kindle-like thing - without amazon