slice2sl 0.3.0 - amd code generation

[kwaclaw]

Seems slice2sl does not generate correct code for AMD.
Tested with this interface declaration:

  interface FSListener {
    ["ami", "amd"] void Changed(string path, string name, byte chgTypes);
    ["ami", "amd"] void Renamed(string path, string name, string oldPath, string oldName, byte chgTypes);
    ["ami", "amd"] void Error(bool isBufferOverflow, string message);
  };

Karl

[dwayne]

Silverlight 0.3 was not meant to support AMD. However, it still should not be generating uncompilable code when the amd keyword is present.

[kwaclaw]

Silverlight 0.3 was not meant to support AMD. However, it still should not be generating uncompilable code when the amd keyword is present.

I am trying to use the new socket transport with call-backs. Would client AMD not be the best way to have the call-back finish the quickest from the server's point of view (two-way call-back)?

Just to explain: The project's purpose is to demonstrate that ICE can do call-backs (even in Silverlight) where web services fail.

[dwayne]

Yes, AMD can give quicker response times if an operation requires further processing after it is ok to send a response back to the caller. However, for an operation which just processes the request and sends the result back to the caller, AMD will not give faster response times.

[matthew]

I am trying to use the new socket transport with call-backs. Would client AMD not be the best way to have the call-back finish the quickest from the server's point of view (two-way call-back)?

If you must have two-wall callbacks you should also consider using AMI on the server side to avoid blocking the calling thread.

[kwaclaw]

If you must have two-wall callbacks you should also consider using AMI on the server side to avoid blocking the calling thread.

Yes, that is what I am doing. Thanks for the advice.