We run the adapters through the PerlServer.java class. An adapter simply prints its expected output to STDOUT, which in the case of a 'backup' operation, it prints the ZiptieElementDocuement(ZED) XML instance document to STDOUT. The java PerlServer knows how to read that STDOUT and collects the ZED XML and parses it.

So the Java PerlServer uses the PerlServer.pl script to call the adapter via an eval. At the end of that eval it sends a well formatted string back to the PerlServer.java, so it knows when the perl script completed.

Out of curiosity, why are you writing a new UI? Are you aware that we are also writing a web based UI for ZipTie, due out late Summer?

I'm also curious about error propogation, because it would be nice to get custom error messages back up to the client. Currently, if an operation fails, you can hover the mouse over the device and see something like SNMP_ERROR or the like. If you click on error details, you often get an overly-technical thing, like a stack trace. How does one push custom error messages up to the client? By simply printing to stdout?

There is no way to "push" error messages to the client. This is mostly intentional. Almost every bit of text displayed in the UI resides on the client and is internationalizable (i18n), with the exception of text that comes directly off of the device or exceptions internal to the server. There is no way for the adapter to know what locale the client is running in, and therefore no way to internationalize text. For example, because ZipTie has been translated into Japanese, if you start the client in a Japanese locale the entire UI is in Japanese.

If you would like to be able to show custom messages on the client, please open an enhancement in the defect tracking system. However, the implementation is going to be very tricky or will have to involve a level of indirection for clients to resolve the message. If someone in China writes an adapter for Huawei but everyone everywhere has to look at Chinese error messages, nobody is going to be happy.

-Brett

What we would like are error codes not messages. For example 0=success, 1=timeout, etc.

Is it possible for an adapter to return an error code? Is it possible to propagate that error code to a custom ZipTie Java client?

The ZipTie::Logger module defines an enum of error constant strings that the server and client use.

The protocol agents (ZipTie::SSH, ZipTie::Telnet, etc) all use these error constants for their various failure situations.

The client uses these string constants as error codes. The idea is that it is easier as a developer to translate "INVALID_CREDENTIALS" to a human readable string than having to know that '4' means the same thing.

- Leo