Re: [tcljava-user] Potential Uses of Tclblend (maybe a bit OT?)

[Patrick F. <pfi...@oz...>]

On Tuesday 13 March 2007 11:11, ni...@ma... wrote:
> Hello all,

>
> 1. Straight sockets. I've been able to test very basic tclclient with
> basic java server and it seems to work.
> I feel this might be too low level and complex for anything realworld.
>
> 2. Ask the java guys to create XML/RPC or SOAP wrappers on their methods
> and call these via tclsoap.
> Here I feel this could work as long as we are only passing url's to the
> source files and not any real (big/complex) data sets. Probably not a good
> idea if we ever have to send any actual data for processing.
>
> 3. Use tclblend to talk to the developed java objects.
> Here I feel alot of work would fall on the tclers understanding the java
> classes, methods etc. Datatypes might also be a concern.Additionally, we
> would not be able to separate concerns either, as IIUC, tclblend talks to
> "resident" java classes. Usage of the java app by third party apps would
> be limited to java based stuff
>
> 4. Have the java guys develop a local (to tcl) java stub/facade that
> tclblend can talk to, maybe via xml-rpc, and then have their stub talk to
> remote java methods via java RMI (of which I know nothing about, but the
> java guys kinda drool over...)
> I feel this approach addresses most of the areas, such as keeping things
> simple for the tcl side, xml-rpc would allow third party usage and layer
> the application and finally let the java guys can worry about datatypes,
> serialization and stuff like that...
>
> thanx in advance for any feedback,
>

Forget 1 and 2.  Java client to Java server is the way to go.  3 is 
problematic if the Java app is now well documented and the Tcl Team are 
reliant on having a working Java app for development and testing.  4 is the 
best choice as it allows the Java developers to develop and test their app 
independently of the Tcl Team.

Your biggest issue could be coordinating the development teams. 

Patrick.