Re: [Communicator-user] Java bindings

[Samuel L. B. <sa...@mi...>]

   We found that writing a Java based server is somewhat different to doing it
   using C. Especially, we are concerned of the signature definition routines,
   initSignatures, SigEntry, Signature and addSignature.  As I have understood
   it, one has to define the exact nature of input and output frames for each
   dispatch function of the server. However in our case we have two problems
   regarding this,

Narada -

This is a good question, and I apologize that the docs are
unclear. The examples in contrib/MITRE/examples/double certainly show
a complete specification of the signature. However, there are a number
of ways of defining the signature. I'm far from an expert on Java;
Steve Wohlever covers that area for us. Normally, I'd let him reply,
but he may be out for a few days for our Thanksgiving break. So let me
give this a shot.

You only need to use the signature stuff if you want to specify a
signature, as shown in the code from
contrib/MITRE/examples/double/java/Multiply.java: 

    private void initSignatures() {
    	SigEntry[] foo = {new SigEntry(":int",GalaxyObject.GAL_INT, Signature.GAL_KEY_ALWAYS)};
	addSignature(new Signature("multiply", foo , Signature.GAL_OTHER_KEYS_NEVER, foo, Signature.GAL_OTHER_KEYS_NEVER, Signature.GAL_REPLY_PROVIDED));
    }

The signatures are used only informationally, for validation
purposes. They're sent to the Hub when the server and Hub connect, but
the only effect they currently have is validation. So to answer one of
your questions, no, initSignatures() isn't necessary. As you're
probably aware, the Java bindings map message names to methods named
"serverOp<capitalized_message_name>", no matter whether a signature is
declared or not. See contrib/MITRE/examples/audio/java for cases where
no signatures are registered.

If you want to use signatures, you can use the constants
Signature.GAL_KEY_SOMETIMES and Signature.GAL_OTHER_KEYS_MAYBE in
the appropriate places to indicate, respectively, that a key is
possible but not required and that other keys are permitted. 

I'll admit that this mechanism wasn't designed for the case you
describe, where you're treating a dispatch function as polymorphic,
essentially. So this mechanism doesn't admit alternative signatures,
for instance. However, the mechanism itself is currently fairly
non-central to the infrastructure, so this particular defect doesn't
concern me much.

If any of this is wrong, I'm sure Steve will chime in, perhaps after
he comes back from vacation.

Cheers,
Sam