Hi John,
> > If an app supplies the metadata at all (either as part of the
> > registration or as separate calls) an API could still respond to the
> > requests automatically in the listener interface even if these never
> > get passed up to the app for special handling (i.e. "built-in
> > messages").
>
> Sorry Mike - could you explain this bit again? I'm not getting it.
Assume we have some API allowing something like
appID = register ((name="myApp"));
(void) appAddMetadata ("Description", "long blather....");
(void) appAddMetadata ("iconURL", "http:....");
:
while ((msgid = appListener()) {
switch (msgid) {
case DISPLAY:
<....>
What I mean is that the appListener() could reply to a request for metadata without explicitly returning that as a message for the application to handle, the same could be done for other housekeeping messages like AreYouAlive, GetStatus, etc. The name and other metadata could be held statically within the API but if the user never made a call to appAddMetadata() the request for the Description would return a NULL.
Anyway, this is an issue for the API developer. The question for us is whether to centralize the metadata in the Hub or access it from the app when requested. Hubs asking remote Hubs for metadata about an app through a message is reasonable. One case where this might get messy is if an app wants to store state metadata likely to change as the app runs; if we centralize in the Hub then each change would require the app to issue an update, if we get it on demand then we only need to check it at the time of the message (if we're ever asked at all).
-Mike Received on 2007-04-30Z21:42:44