Eric Day wrote:
On Tue, Nov 25, 2008 at 07:07:06AM -0800, Barry Leslie wrote:
As Tim mentioned, the BLOB streaming engine stores the MIME type
along with the BLOB data in the repository.
BLOBs are uploaded with HTTP PUT and downloaded with HTTP GET so
considering the MIME type to be part of the BLOB is easy and
extremely practical.
What about all the other pieces of potential HTTP metadata?
Theoretically it could all be stored in the repository. But I think
the content type, which includes the charset information, is the most
important.
Rather than just storing selected HTTP header fields we could just store
them all as one block of text. They could then be packed back into the reply
header when the blob is read back. If people are interested in particular
header fields they can process the text themselves. This way we are not
trying to guess in advance which http headers are important to people and
which are not.
Content type and charset could maybe have their own column.
Hi everyone!
Since we are already in a database, why not store this structured
data into real columns, rather than another unstructured block that
needs to be parsed by the application. This gives the user control
of what to store, and the HTTP GET/POST interfaces can be modified
to return/store the headers if the columns exists (or are configured
in some way). Also, applications may want to access those fields
outside of the blob interface, which would be easier if they were
normal columns.
Putting headers in their own little blocks or creating special
attributes just seems a bit hackish.
Give the man a Kewpie doll. He got the right answer.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
