RE: [tcljava-user] JACL - Urgent help to make a design decision!

[Lehmann, E. {TR-I~Penzberg} <eck...@ro...>]

Hi,

maybe tclBlend is a better approach for such a project?=20

Jacl is Tcl, implemented in java - and therefore good if you want to add =
a Tcl console to your existing Java program.=20
On the other hand site, tclBlend connects the real, native Tcl you have =
installed with a real Java Virtual machine, using JNI. So it should be =
possible in an existing native Tcl interpreter to do=20

% package require Expect
% package require Java

without problems. With tclBlend you can port parts of your existing Tcl =
code to Java and make these parts as well as other Java code to commands =
for use in Tcl - and you are able to instantiate and use Java API =
classes (such as java.awt.*, java.net.*...) directly from Tcl.
So you could develop an RMI server in Java, wrap it as a Tcl command, =
then instantiate it from within a Tcl script (or instantiate it directly =
without wrapping) and change its state from the Tcl script. The client =
connects to the Java server and communicates only with the Java server =
(and does not know about the underlying Tcl script).

If I understood your project goals right, this is what you want, isn't =
it?

TclBlend worked fine when I played around with it, and I would trust in =
it for real projects. However, I don't know much about licensing...


Eckhard


> -----Original Message-----
> From: tcl...@li...=20
> [mailto:tcl...@li...] On Behalf=20
> Of Fernando M. Dagostini
> Sent: Tuesday, December 14, 2004 8:35 PM
> To: TclJavaDevel SourceForge; TclJavaUsers SourceForge
> Subject: [tcljava-user] JACL - Urgent help to make a design decision!
>=20
>=20
> Hi! All,
>=20
> I am about to make a high level design decision for a project=20
> in the company I work for.
>=20
> --- Brief:
>=20
> We currently have a relatively large (12 Kloc) application=20
> coded in Tcl/Tk/Expect or Expectix. The application provides=20
> a whole bunch of functionalities to the user via Tk widgets=20
> and accesses system resources in the backend including=20
> Socket, File Handling, Spawning external executables, etc.
>=20
> All this is part of a larger system in the Wireless CDMA=20
> network management.
>=20
> Then environment is Sun Solaris.
>=20
> --- Objective:
>=20
> Now, we are migrating parts of this larger system into a=20
> newer one which is Java Client/Server based architecture -=20
> including Java/RMI for Client/Server communication.
>=20
> We have estimated that the application as is today is=20
> balanced between:
>=20
> - 1.5 Kloc of Tk front end code (GUI)
> - 10.5 Kloc of Tcl/Expect back end code
>=20
> in a single script file - yes, total of 12 Kloc in a single=20
> program file!...
>=20
> Needless to say that our first thought was to port the GUI=20
> part of the application to the Java Client and reuse the=20
> backend part entirely, with little adjustments, in the=20
> Server. To accomplish this we would like to implement a=20
> collection of simple Java/RMI classes - basically to map=20
> remote client calls directly into Tcl procedures - and glue=20
> them to via Jacl.
>=20
> So, Jacl would be extremely useful in the sense that:
>=20
> - Would save a  lot of effort w/o having to port the backend=20
> code.
> - Clean design.
> - Would fit as a glove into the new Server system.
>=20
> --- Questions/Problems:
>=20
> 1 - Is this really an approach that Jacl can support.
>=20
> 2 - I've noticed that the "package" command "...completely=20
> implemented in Jacl."  as stated in the DIFFS.TXT file so, I=20
> am assuming that I can load the Expect extension by issuing=20
> the command "package require Expect", is this correct?
>=20
> 3 - I've gone through all the commands mentioned in the=20
> DIFFS.TXT and found that, at least based on what is stated=20
> there, I can get around those commands listed in "What=20
> Partially Works" with minor changes in the Tcl code.
>=20
> 4 - I've tried step 2 above in a Jacl shell command line but=20
> it didn't work. If it should work what am I doing wrong?
>=20
> 5 - What are the licensing restrictions that may apply to=20
> using Jacl in such a project?
>=20
> 6 - Are there other implications that I should care about?
>=20
> Sorry for the long posting - we are really interested in=20
> using Jacl but the project is large enough to take high risks=20
> at this point.
>=20
> We appreciate your opinions/suggestions.
>=20
> Regards,
>=20
> Fernando M. Dagostini
>=20
> Brazil Technology Center - Finatel
> E-mail: fd...@no...
>=20
>=20
> =20
> ______________________________________________________________
> ____________
> Acabe com aquelas janelinhas que pulam na sua tela.
> AntiPop-up UOL - =C9 gr=E1tis!
> http://antipopup.uol.com.br/
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users. Discover which products truly live up to the=20
> hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> tcljava-user mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-user
>=20