<--even more next stage, continued ^--Soigan--^

Soigan - a Multicast XML monitoring system - stage 4

Well, the specifier change went in quite quickly and painlessly. As mentioned, I added "schema" to the schemas, so we no longer have special functions for retrieving schemas -- we just as about the Service with a "schema" specifier.

"callback" is used for unsolicited Responses from Workers, to let the Server know that it didn't ask for it. This might be a problem, for what if a Client asks for service.query("who@*")? The Client will expect results for both "who:default@*" and "who:callback@*", but not the one-off calls being made by other Clients. Right now, though, the above call will translate into "who:default@*", and miss the callbacks. What's the solution? Do we hack the Service-matching code to make "default" also match "callback"? Or do we make unsolicited calls still use default? It all comes down to what the difference is (to the Server) that it's unsolicited. Right now we're not handling it any different than an expect Response, but we probably should. But at that point, the Server can determine whether it expected it or not, and doesn't need the Service name to say so. Hmn. I'll have to re-consider this.

When writing up my Plugin Howto, I realized that the way I was outputting from the Plugins was silly with respect to the structures and their named members:

Before:

string
who@host
date
1086728665972
struct
int
count
1
array
struct
string
login
crwth
string
tty
pts/1
date
when
1086098520000
string
from
stilton
end
end
end
After:
string
who@host
date
1086728665972
struct
count
int
1
array
struct
login
string
crwth
tty
string
pts/1
when
date
1086098520000
from
string
stilton
end
end
end
The difference? I changed it from
<datatype>
<membername>
<data>
to
<membername>
<datatype>
<data>
This keeps the general structure of the simple types (strings, ints, doubles, booleans, date) the same -- typename followed by data -- throughout the system. Structures were the only time that something extra was supplied (the member name), and I foolishly put it in the middle of the definition. No longer.

I've also changed the structure of a Result. Previously, I would return (to service.query() and service.run()) an array of structures, those being the same structures that were returned to the Server from the Worker - that is, the Response structure.

The problem was that when used with wildcard Services, such as "who@*", you would get back an array of structures, but have no idea which one related to which! There would be a list of users logged into a machine, and there's yet another, but who's on what? Oops.

Now a Result is a structure containing three members:

This structure is what is sent to the Client if it has registered itself for a Service, whether a specific one ("who@nsd") or wildcard ("who@"). Every Response the Server receives will cause it to call service.result() on the Client. In the case of service.query() and service.run(), an array of the above is returned.
<--even more next stage, continued ^--Soigan--^
©2002-2017 Wayne Pearson