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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Darn, the implants itch something fierce...