Markus,
What happens when one box can function either as an origin/replica
server or
an intermediary? Is it a server or a proxy? When my service plug-in
runs
there, is it a servelet or a proxylet? Or do we need more general name
for
the box? A "service node" perhaps?
This depends on the data flow. When the piece of code is called from
the server part of the box, it's executed as a servlet; if the code is
called from the proxy part of the box it's called a proxylet. Proxylet
and servlet refer more to the data flow than to the actual piece of
code.
The distinction between "parts of the box" may not exist.
If everyone can run on the same box, then all that distinguishes the
servelet from the proxylet is API.
Why do you assume that server and proxy have a different API? For
example, if both boxes offer a CGI interface, I can take the same
virus scanning software and run it on a proxy as proxylet, and on a
server as servlet. The difference is in the data flow. I'm probably
missing something here...
No, I don't think you are. It's just a question of whether the name refers
to something inherent in the -let or to the way it is used. Either way is
problematic, since as you correctly point out proxy and server APIs are not
disjoint, and even if we associate the name with the API, there will
be -lets that are both. However, at least you'll be able to tell that that
they are both by looking at them.
Going with the -let name as a descriptor of the execution environment rather
than the code leaves us with the problem of coming up with a new name for
every new execution environment. Some people already don't like "proxy". I
guess I could call all code run by an edge server that supports both proxy
and server APIs an "edge servelet," and then differentiate between APIs
within that category.
The fundamental problem is that historically servers and proxies have been
distinct boxes, and their APIs were quite disjoint, so naming servelets and
proxylets according to where they run also categorized them by API. All
very intiutive, but not very general. Now, as you point out the APIs are
not disjoint,as I'm pointing out the boxes and the controlling software may
be identical. Since the basis for the distinction was historically
operational rather than semantic, and the operations are getting blurred we
now have a problem with naming.
Naming by API does not yield disjoint categories for servelet and proxylet,
but it gives us a well-defined naming scheme that tells you something
inherent about the code being named (it corforms to a particular class of
API). Naming by execution environment does not yield disjoint categories
and also does not tell us anything inherent about the code (it's a proxylet
if it's running on a proxy, it's a servelet if it's running on a server,
it's an overlaylet if it's running on an overlay repeater, ...).
Either way will work, neither is perfect... perhaps it's a matter of taste.
/micah