Interface "discovery"

Hi,

I have applications from different sources coexisting in the same arena. Applications store their configuration and operating parameters in application-specific "databases" (let's not argue the semantics of that term).

This is similar to MS's registry except much more free-form (e.g., applications aren't constrained to the "type-less" datatypes that MS supports but can use any of a variety of types) and structured (though that seems like a conflict in terms)!

The application decides *who* gets to see *what*. Likewise, there are constraints on who can *diddle* with what.

But, in order for two (or more) applications to co-operate, there needs to be a means by which one application can discover the parameters applicable to the "other" application(s). The MS Registry parallel would be:

- know the portion of the key hierarchy related to the application (for me, this is similar to knowing which database to access)

- know the names of the particular keys to access (for me, the names of the appropriate "fields"/columns)

- ... and their expected data types (for me, more choices than the few registry offers)

- ... and the constraints placed on those values (for me, constraints placed on the fields' values and relations to other fields/records)

The last two aspects are relatively easy for me to solve

*once* I have handles to chase down (names of fields, etc.).

The first two are the problem area.

AFAICT, the only practical solution is to require applications to inherently know this information. I can't envision a scheme whereby an application can *discover* this information (unless you add another layer of abstraction and a mapping function that essentially relates those abstractions to "specifics"). And, that would just kick the can down the road one level... you would still need to "standardize" this "abstraction interface".

Or, is there some clever meta-data scheme that I could exploit (probably with a different *implementation*) to formalize these interfaces?

[I suspect the "answer" is "No, apps need to know what they are looking for, implicitly/explicitly"]

Thanks!

--don

Reply to
D Yuniskis
Loading thread data ...

What am I missing here? Define a standard rendezvous location where each app stores a key/folder/whatever you want to call it, named with a UUID for the application, or the application's name itself, and containing a description of where it is and how to talk to it.

You could probably coopt existing code from UPnP or OSGI or something and just use your "registry" as the transport layer.

Reply to
larwe

Mechanism isn't the problem. As I said, the data types, constraints, etc are readily available (at least as far as the nouns are concerned; I'll have to modify my IDL compiler to generate the required data for the verbs, as well).

The problem was the "know the..." issues I mentioned. In particular, I couldn't see how adding another layer of abstraction would make things any better... Another respondent has shown how the added layer has *practical* advantages as well as issues related to interfacing to that layer.

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.