[
Lists Home |
Date Index |
Thread Index
]
> 2. A binary used for internal dbms representation is not likely
> to be interoperable. Broadly, a binary for ANY document
> type specific representation isn't likely to be interoperable
> and any general representation isn't likely to be efficient.
> So evolution tends toward application-specific binaries and
> each application language specification specs it'w own. A
> dbms binary IS an application-specific binary and one doesn't
> get the kinds of agreements in the dbms space as one does
> in other application spaces (say, rendering clients).
>
>
> The use of application binaries to get performance complicates things,
> and yet, we will have them.
>
Hmmm. There are benefits from standard binary formats such as JPEG and MPEG-4 --
interoperability being the primary benefit.
Let's not be too quick to dismiss the benefits of having DBMS clients that
understand the binary representation used to store the data, and being able to
communicate with the server using data in that format.
Secure client-server document exchange and encryption come to mind. If you have
an application that mandates the secure exchange of documents between client and
server, you're going to have to burn client cycles to encrypt/decrypt the XML
data. There might also be a requirement the XML document or fragments be
stored in an encrypted form in the database.
If you're burning client cycles to encrypt, why not present the data to the
server in a form it can use?
Because you're operating in a secure document processing mode, you've already
incurred the overhead of authorization and authentication. You're passing data
from a trusted client to a trusted server, and vice-versa.
|
