If that's the case (we want to be able to put all kinds of roles onto one
map), can we just clearly define "RUP-Client" and "RUP-Server" (note the
hyphen and the capital case of C and S)? then just say these are two
special terms for certain roles, in this picture?
or "RUP Publisher" and "RUP Subscriber", for that matter?
At 06:56 PM 11/12/01 -0800, Mark Nottingham wrote:
>Publish/subscribe is fine by me, as long as we are willing to be
>tarred by that brush at this point.
>
>There isn't anything to prevent an intermediary from being both a
>publisher and a subscriber (or client and server, or producer and
>consumer) at the same time. It's useful to separate the roles that
>the message endpoints play from the role that the network nodes play,
>IMHO. In HTTP, this allows you to compose things like
>
>
> +---------------+
> | user-agent |
> + - - - - - - - +
> | client |
> +---------------+
> |
> +---------------+
> | server |
> + - - - - - - - +
> | proxy |
> + - - - - - - - +
> | client |
> +---------------+
> |
> +---------------+
> | server |
> + - - - - - - - +
> | gateway |
> + - - - - - - - +
> | client |
> +---------------+
> |
> +---------------+
> | server |
> + - - - - - - - +
> | origin server |
> +---------------+
>
>and talk unambiguously about the roles being assumed by the nodes.
>
>
>
>
>On Mon, Nov 12, 2001 at 06:30:00PM -0800, Dan Li wrote:
> > At 05:55 PM 11/12/01 -0800, Mark Nottingham wrote:
> >
> > >My suggestion: producer/consumer, perhaps qualified by 'payload' or
> > >'invalidation' if in that scope.
> >
> > I think producer/consumer is better than invalidator/listener. The now
> "RUP
> > server" has up-to-date knowledge of what's changes and produces the
> > up-to-date view of the content, while the now "RUP client" subscribes to a
> > certain update channel to receive (or, consume) such up-to-date view.
> >
> > Master / slave may describe this relationship too.
> >
> > Also, publisher / subscriber.
> >
> > Dan
> >
> > >The point is that although 'client' and 'server' sound good because
> > >they are familiar, they are misleading, especially at this early
> > >stage.
> > >
> > >
> > >On Mon, Nov 12, 2001 at 05:49:45PM -0800, Joseph Hui wrote:
> > >> What replacement candidates (for "RUP client" and "RUP server")
> > >> do we have in queue now?
> > >>
> > >> To me, the "invalidator" for client, "listener" for server,
> > >> "content viewer" and "content publisher" that Ian was alluding
> > >> to don't sound like superior alternatives.
> > >>
> > >> Joe Hui
> > >> Digital Island, a Cable & Wireless company
> > >> =======================================================
> > >> > -----Original Message-----
> > >> > From: Mark Nottingham [mailto:mnot@akamai.com]
> > >> > Sent: Monday, November 12, 2001 5:19 PM
> > >> > To: Joseph Hui
> > >> > Cc: Ian Cooper; Dan Li; webi@lists.equinix.com
> > >> > Subject: Re: Open issue: RUP system roles
> > >> >
> > >> >
> > >> >
> > >> > Well, count me among them, I guess. People have many conceptions
> > >> > about what 'client' and 'server' mean, especially since we're talking
> > >> > about a system/protocol that is to be used in conjunction with
> > >> > another which already defines these roles (Web/HTTP). I'd note that
> > >> > both 2616 and 3117 define them in terms of roles in a
> > >> > request/response message exchange pattern.
> > >> >
> > >> > I think the meaningful differentiation for us, at this point, is
> > >> > between the party that produces the payload and that which consumes
> > >> > the payload. This is independent from who initiates the connection,
> > >> > who sends the first message in a connection, etc.
> > >> >
> > >> > If we can craft clear definitions of these roles as 'RUP Client' and
> > >> > 'RUP Server', using these criteria, I don't have a problem with that.
> > >> > However, we may want to save these terms for the more traditional
> > >> > roles that they play; client/server has a lot of implications that we
> > >> > might not want to emulate.
> > >> >
> > >> > IIRC, 'inbound/outbound/upstream/downstream' was frowned upon by
> > >> > WREC, because it's very dependent on context.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Mon, Nov 12, 2001 at 04:53:12PM -0800, Joseph Hui wrote:
> > >> > > "Client" and "server," imperfect some may think they are,
> > >> > > convey a strong sense of message direction -- which is in my
> > >> > > view important -- because of the *inbound/outbound/upstream/
> > >> > > downstream* connotations (as defined in HTTP 1.1), even in
> > >> > > the case where a content signal relaying node plays the role
> > >> > > of server to its *downstream* neighbor as well as the role of
> > >> > > client to its *upstream* neighbor.
> > >> > > Are there candidates that can do better?
> > >> > >
> > >> > > Joe Hui
> > >> > > Digital Island, a Cable & Wireless company
> > >> > > =============================================================
> > >> > >
> > >> > > > -----Original Message-----
> > >> > > > From: Ian Cooper [mailto:ian@the-coopers.org]
> > >> > > > Sent: Monday, November 12, 2001 4:34 PM
> > >> > > > To: Dan Li; webi@lists.equinix.com
> > >> > > > Subject: Re: Open issue: RUP system roles
> > >> > > >
> > >> > > >
> > >> > > > --On Monday, November 12, 2001 16:12 -0800 Dan Li
> > >> > > > <lidan@cisco.com> wrote:
> > >> > > >
> > >> > > > > I think we settled on "RUP server" and "RUP client". The
> > >> > > > > terminology's section defines these two terms, then throughout
> > >> > > > > the text we used only "RUP server" and "RUP client", and
> > >> > > > > avoided using "server" "client". -- This change happened after
> > >> > > > > the comments from the last IETF
> > >> > > > and email, etc.
> > >> > > >
> > >> > > > Fair point but I don't see any discussion on whether
> > >> > those terms were
> > >> > > > "settled on" (maybe the web archive missed something?).
> > >> > > >
> > >> > > > My point is that the words "client" and "server" are pretty
> > >> > > > strictly defined terms (especially in HTTP), so just putting the
> > >> > > > prefix "RUP" in front may not be sufficient.
> > >> > > >
> > >> > > > Do we want the potential confusion of a RUP server that's acting
> > >> > > > as a client and a RUP client operating as a server?
> > >> > > >
> > >> > > >
> > >> > > > The clarification you put in place as a result of comments at the
> > >> > > > London IETF might be sufficient - I'm asking for folks to voice
> > >> > > > their opinions on whether that's the case, because I can't
> > >> > > > actually see any comments on that point.
> > >> > > >
> > >> > >
> > >> >
> > >> > --
> > >> > Mark Nottingham, Research Scientist
> > >> > Akamai Technologies (San Mateo, CA USA)
> > >> >
> > >>
> > >
> > >--
> > >Mark Nottingham, Research Scientist
> > >Akamai Technologies (San Mateo, CA USA)
>
>--
>Mark Nottingham, Research Scientist
>Akamai Technologies (San Mateo, CA USA)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:23:00 MST