At 05:09 PM 4/18/01 -0400, Ann W. Harrison wrote:

>
>
>OK, so how would you represent multiple roles? For logging,
>for example... ?
>

[Nothing like communicating with a person three and a half feet
away through a list server...]

The existing mechanisms for passing data from server to client are
these: a) Info calls (request, transaction, database), b) blr
value expressions and the ilk, c) results sets from system
tables, pseudo system tables, stored procedures, and the like,
d) system defined "udfs".

The info calls are dandy, but require that the transaction
handle and API be exposed and that he host language be able
to handle gook. I like 'em, but I'm probably the only one.
Let's count them out.

Blr value expressions eat into blr space, require non-standard
SQL syntax to support them (oh, look, Jim is arguing against
non-standard!). They also don't lead to returning complex
data (multiple role, each with active indicator).

Semi-magic result sets are the accepted way to handle this sort
of crud in ODBC/JDBC. They're easy to define and easy to extend
when you discover that you forgot something. On the other hand,
if there are lots of nasty little items to support you either
have to give the user everything (is this really a problem?)
or invent some mechanism to say what you want. Doable, but
maybe more mechanism that you want to invent. On the other
hand, "semi-magic" result sets a la ODBC/JDBC require additional
API calls, extensions to remote protocols, version skew, etc.
Pseudo-system tables (tables real or imagined) are preferable
(if the ODBC goons could have agreed on name space issues, they
probably would have done this).

System defined UDF, like the doomsday function but without
the side effects, would be easy and embeddable in stored
procedures. On the otherhand, I'm about the only person
who doesn't like Interbase stored procedures, so I'm not
particularly enamored with this solution. A more rational
person might want to run with it, however.

We can probably invent some alternatives. Netfrastructure
has a neat mechanism to open a "service connection" into
a server to import executable serialized object clusters
for interserver communication. But that requires embedded
Java...


Jim Starkey