Yes, the expected set of API is critical to making the
operation "code fragments" work (whatever-LET).
This is why7 I think we need to have the API suite as part
of the specifications.
I like the name "edge servlet" - when it comes time we can consider this.
We changed our original name from Open Proxy Extensible Services
to Open Pluggable Edge Services because the intermediary device
goes far beyond the concepts associated with a proxy. So the
name "proxylet" is a hold-over from the original requirements.
At 10:18 AM 3/6/2001 -0500, you wrote:
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
Michael W. Condry
Director, Network Edge Technology