[ticker-dev] Why Attachment field as byte array?

[Ian Lister]

On Thu, 15 Aug 2002, David Arnold wrote:
>-->"Ian" == Ian Lister <ilister at dstc.edu.au> writes:
>  Ian> What about allowing it to be either an opaque or a string (but
>  Ian> still forbidding any encodings that aren't currently allowed)?
>
>there're no encoding forbidden now, it's just that they're not
>necessary?

Oh, OK, I wasn't sure (which was why I carefully phrased my sentence to
still be technically correct even if that was the case ;-)

>i worry about
>
>   contains(Attachment, "x-elvin/url")
>
>being evaluated over images and Word files.  it's gonna chew a lot of
>CPU.  making it opaque prevents this nicely, and makes people route on
>the "content" (as distinct from the attachment).

A producer attaching a binary file can still use the opaque type.

This seems like a drastic limitation on common use for the benefit of
(currently) rather uncommon use.

I'm not sure it's a good idea to go out of our way to stop people routing
on particular parts of the content (and I think the attachment is still
part of the content, even if the name makes it sound less important).

It also goes to show that bundling all the MIME stuff into a single
attribute is not optimal for content based routing. It's really quite
similar to throwing an XML document into a single attribute; it makes it
hard to match on the logical elements that are a part of that attribute.

>but does it break people's usage?

Currently people route on channels, and that's just about it. I can think
of lots of cool things to do with routing on the attachment content, and
maybe nobody will ever implement them, but they certainly won't be able to
if it's opaque.

Ian