new requirements for attachments

I had an AI to harvest any new reqirements for attachments that have
surfaced.

The following candidates have been identified:

1) Reduce "bytes on the wire", to improve bandwidth usage / transport
latency.  [ related to R4 ]

2) Reduce processing overhead during the generation and consumption of
messages.  [ related to R3 ]

3) Enable selective reordering in the serialization of message components,
to allow flexibility in processing.  [ related to R26 ]

4) A requirement related to #3, high on our list, is "early" information
on the serialization parameters.  Knowing the size of objects before they
come at you on the wire allows much more efficient response when the
receiver resource are limited.  Knowing that you will not be able to
handle an object allows early and more useful user feedback.  [ related to
R21 / R31 ]

5) Another [requirement] would be that it's an optimisation mechanism;
i.e., it can be gracefully backed out without loss of functionality (so
that you can still communicate across non-aware hops, for example).  [
related to R18 ]





--
Mark Nottingham

Received on Monday, 21 July 2003 16:18:19 UTC