From: Masaharu Kobashi (mkbsh@cs.washington.edu)
Date: Tue Oct 12 2004 - 20:28:19 PDT
1. Main result of the paper
The paper proposes a design principle that helps system designers
to decide on what functions be installed at what level.
It describes many situations where functions should be moved
up to the application level (end) instead of installing at a lower
level presenting plenty of examples.
2. Strengths in this paper
The authors provide plenty of examples to explain their principle.
As far as those examples are concerned, they make good cases to
support their claim.
It provides some insight in designing a system in determining what
functions be put at what level.
3. Limitations and suggested improvements
They show a lot of example cases where functions should be moved
up higher to the end points. If there are functions that are
appropriate to be at the end points (applications), are there any
functions that are not appropriate for the end-to-end?
They do not even touch upon this side of the argument.
There can be arguments against end-to-end. For example, for those
functions that are shared by all or most of applications and do not
do any harm to their performance or logical correctness can be
rightfully installed at a lower level for the economy that many
applications can share them, hence they can be collectively relieved
of some burden.
The authors also say about low level mechanism as "justified ONLY
as performance enhancement". But there are great number of cases
in the real world where performance is the paramount importance.
In those cases, having duplicate functions at multiple levels
is not a big problem as long as the vital goal, performance, can
be attained. Authors seem to be a little biased and think little of
performance because of their passion for making clean designs where
no redundancy exists.
4. Relevance today and future
The proposed design principle is fine. But as long as those examples
described in the paper are concerned, what they propose is probably
obvious to most designers. As a practical matter, what is hard is
to decide on the trade off among different goals such as performance
and costs. As to the decision on this aspect the proposed guide is
of no value. The authors say "the designer may be tempted to help
the users by taking on more functions than necessary". But what is
hard is to decide on what is the necessary functions at each level.
As to this question, the paper does not provide a general principle.
It presents only answers to some individual cases.
This archive was generated by hypermail 2.1.6 : Tue Oct 12 2004 - 20:28:20 PDT