Re: [tcljava-dev] JACL - Urgent help to make a design decision!

[Neil M. <ne...@cs...>]

Hello,

Some answers below

On 14 Dec 2004, at 19:34, Fernando M. Dagostini wrote:
   [...]
> Needless to say that our first thought was to port the GUI
> part of the application to the Java Client and reuse the
> backend part entirely, with little adjustments, in the
> Server. To accomplish this we would like to implement a
> collection of simple Java/RMI classes =96 basically to map
> remote client calls directly into Tcl procedures - and glue
> them to via Jacl.
>
> So, Jacl would be extremely useful in the sense that:
>
> - Would save a  lot of effort w/o having to port the backend
> code.
> - Clean design.
> - Would fit as a glove into the new Server system.
>
> --- Questions/Problems:
>
> 1 =96 Is this really an approach that Jacl can support.
>
> 2 =96 I=92ve noticed that the =93package=94 command =93=85completely
> implemented in Jacl.=94  as stated in the DIFFS.TXT file so, I
> am assuming that I can load the Expect extension by issuing
> the command =93package require Expect=94, is this correct?

I'm afraid not. Expect is a compiled extension for C-based Tcl. It=20
won't work with the pure-Java Jacl. You could use C Tcl/Expect as=20
before and use the TclBlend extension (part of the same project as=20
Jacl) which will allow you to load extensions written in Java into a=20
normal Tcl shell. This is essentially the reverse of the situation you=20=

describe - instead of embedding Jacl into your application, structure=20
the Java parts of your application into packages which can be loaded=20
into Tcl via TclBlend.

Another alternative is to try and port the parts of your app that use=20
Expect to use Java or pure-Tcl/Jacl scripts. Depending on what you use=20=

Expect for this could range from trivial to insanely=20
difficult/impossible. I don't know of any attempt to port Expect to=20
Java/Jacl, and I doubt it is even possible. =46rom what I gather, Expect=20=

does some very low-level magic, and it is quite likely that this sort=20
of control isn't available in Java.

>
> 3 =96 I=92ve gone through all the commands mentioned in the
> DIFFS.TXT and found that, at least based on what is stated
> there, I can get around those commands listed in =93What
> Partially Works=94 with minor changes in the Tcl code.
>
> 4 - I=92ve tried step 2 above in a Jacl shell command line but
> it didn=92t work. If it should work what am I doing wrong?
>
> 5 =96 What are the licensing restrictions that may apply to
> using Jacl in such a project?

Jacl, like Tcl, is BSD-licensed, so you can do pretty much whatever you=20=

like with it. There should be a license.terms or similar in the=20
distribution which gives the full license details. It's quite short :-)

>
> 6 =96 Are there other implications that I should care about?
>
> Sorry for the long posting - we are really interested in
> using Jacl but the project is large enough to take high risks
> at this point.

Somebody else might be able to fill in any gaps I've left in the above.

Cheers,

-- Neil
Neil Madden (ne...@cs...)
PhD Student, Intelligent Agents Group,
School of Computer Science & IT,
University of Nottingham. NG8 1BB. UK.=