Subject: Re: CAP (fan out) - latest intem draft

From: [email-masked]
Date: Wed, 9 Jan 2002 16:28:26 -0500

Doug suggested:
>            Fan out is the ability for one CS to interact
>with another CS in order to appear to be one logical CS.

Actually, the current definition as cited is closer to the original concept
of fan out.  The original concept was much like SMTP where the CUA would
just give the CS a single request ("Send this request to Doug, Steve, Pat
and Bob") and the CS would handle routing the request to the next
appropriate CS to deal with (or further route) the request; the CUA would
just sit and wait for the responses that come back as "the magic happens".

>  The calendaring and scheduling process by which one CS
>  communicates to another CS on behalf of the CUA. This
>  may be with or without the CUAs knowledge.

Im not sure this is a good idea!  If the CS is trying to be nice for me and
do some stuff on behalf of my CUA, I may wind up with 'duplicate data'
because my CUA goes out and does the exact same actions on its own (not
expecting the CS to be so accomodating).  This is a Bad Thing, not
something we really want (user confusion and interop hell galore).  The CS
should somehow have a clear and consistant way to tell the CUA "Im going to
do Fan Out for you" to prevent both duplication of effort and data...  We
would probably need some way for a CUA to tell the CS "Thanks but no
thanks, Ill do it all myself" too.  Hmmm...

>                                              Note that CAP
>  does not specify how fan out should be done.

Yep, its currently an exercise for those w/gray cells to burn (and fingers
to blunt on keyboards).  However w/o a common definition of what Fan Out
is, ya cant get there from here.  So far we have 2 slightly different views
on what the same term means.  We need to clearly distingish them both since
they both have different implications for implied behaviour.

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked]
Darn, the implants itch something fierce...

---

From: George Babics <[email-masked]>
Date: Thu, 10 Jan 2002 14:36:18 -0500

[email-masked] wrote:
> Actually, the current definition as cited is closer to the original concept of fan out. The
> original concept was much like SMTP where the CUA would just give the CS a single request ("Send
> this request to Doug, Steve, Pat and Bob") and the CS would handle routing the request to the next
> appropriate CS to deal with (or further route) the request; the CUA would just sit and wait for
> the responses that come back as "the magic happens".
> 
> Im not sure this is a good idea! If the CS is trying to be nice for me and do some stuff on behalf
> of my CUA, I may wind up with 'duplicate data' because my CUA goes out and does the exact same
> actions on its own (not expecting the CS to be so accomodating). This is a Bad Thing, not
> something we really want (user confusion and interop hell galore). The CS should somehow have a
> clear and consistant way to tell the CUA "Im going to do Fan Out for you" to prevent both
> duplication of effort and data... We would probably need some way for a CUA to tell the CS "Thanks
> but no thanks, Ill do it all myself" too. Hmmm...

  If we do have fan out to a later version of CAP, we can add
a new command that allows the CUA to turn fan out "on."
By default, the CS will not do fan out.

> Yep, its currently an exercise for those w/gray cells to burn (and fingers to blunt on keyboards).
> However w/o a common definition of what Fan Out is, ya cant get there from here. So far we have 2
> slightly different views on what the same term means. We need to clearly distingish them both
> since they both have different implications for implied behaviour.

  We may also simply remove the definition
since we have decided not to do fan out in the
first version of CAP.

George

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 12:59:44 -0700

> >with another CS in order to appear to be one logical CS.

Would everyone agree that as fan-out is already out of scope
for CAP. We remove all references to fan-out entirely from CAP?

> Actually, the current definition as cited is closer to the original
> concept of fan out. The original concept was much like SMTP where the
> CUA would just give the CS a single request ("Send this request to
> Doug, Steve, Pat and Bob") and the CS would handle routing the request
> to the next appropriate CS to deal with (or further route) the
> request; the CUA would just sit and wait for the responses that come
> back as "the magic happens".
> 
> Im not sure this is a good idea! If the CS is trying to be nice for me
> and do some stuff on behalf of my CUA, I may wind up with 'duplicate
> data' because my CUA goes out and does the exact same actions on its
> own (not expecting the CS to be so accomodating). This is a Bad Thing,
> not something we really want (user confusion and interop hell galore).
> The CS should somehow have a clear and consistant way to tell the CUA
> "Im going to do Fan Out for you" to prevent both duplication of effort
> and data... We would probably need some way for a CUA to tell the CS
> "Thanks but no thanks, Ill do it all myself" too. Hmmm...
> 
> >                                              Note that CAP
> Yep, its currently an exercise for those w/gray cells to burn (and
> fingers to blunt on keyboards). However w/o a common definition of
> what Fan Out is, ya cant get there from here. So far we have 2
> slightly different views on what the same term means. We need to
> clearly distingish them both since they both have different
> implications for implied behaviour.
> 
> Bruce