httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Thoughts on filter-chain composition
Date Wed, 13 Sep 2000 01:27:44 GMT

In a message dated 00-09-12 12:50:44 EDT, v.j.orlikowski writes...

> With the CC/PP headers, we'd be able to determine what kinds of encodings
> the said device could handle, and then perform the needed transcoding via
> setting up the filter chain in advance. We would have the information on
> what kind of content the device can handle, and we would have the info
> from the content on the server (i.e. the headers from the gif image, for
> example).
> But, as has been said, this advance setup can only be partially done,
> since not all the info is encoded in the header of the file to be
> filtered.
> So, the filters need to be written in such a manner that, when a given
> filter runs into a "feature" of the content that it cannot handle, 
> it is able to insert the proper filter into the chain in order to
> take care of things.


New schemes that come along and provide MUCH more metadata
for everyone concerned ( That's what XML is all about ) will be great
and will just make it all easier... but there will still be .GIF and .HTML
files flying around 30 years from now and the basic concepts of
flitering won't have changed by then, either.

Anything that is asked to filter a stream of data that is only going
to be given little 'bits and pieces' of the actual data ( buckets )
as it arrives will never be always able to 'know' everything it might have 
to do to get the job done until the data is actually arriving.

Any scheme that says it does is just going to be Dead Man Walking.

It all depends on what the filtering job requirements are and what
the data actually 'looks' like.

I guess what I am saying is that anytime a good pile of 
'metadata' ( Information about the data that is outside the data )
can tell you all you need to know about the data and what 
might need to happen at all times while filtering it... that's GREAT.

But sometimes there will always be...

intra-data-metadata ( Information about the data only found inside the data ).

Example: GIF97A extension blocks. They only exist to give you information 
about the graphics data but they are inside the data at unpredictable points 
and they are not part of any metadata or even the image header itself.

Kevin Kiley
CTO, Remote Communications, Inc. - Online Internet Content Compression Server.

View raw message