Draft minutes 14th March

["Martin Chapman" <martin.chapman@oracle.com>]

CAF Telecon - 14 March 2005


Agenda Review: no changes

Scribe: Jeff Miscgkinsky

Roll Call: in kavi: http://www.oasis-open.org/apps/org/workgroup/ws-caf/event.php?event_id=4150

Meeting is quorate

Minutes: Approve minutes 28 Feb 2005.
http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200502/msg00225.html 

  Mark/Tony - unan

AI Review:
    Martin separated AI's for editors and sent them to editors

Kevin: plan implementation -- report at this call
    sent out proposal -- by new orleans support Context, by June f2f 
work on coordination impl
    Closed

Greg and Doug - solution to must understand -- pending -- this week

Editor's Update
     status on coord - mark and greg's part completed -- waiting for 
eric to complete his items -- will finish up by the end of the week
     new target 21 march for draft and schema -- editor's call on 
thursday 20 mar

Impl subteam/plan discussion:

Greg: coord requires layering on some sort of an implicit protocol -- 
greg wonders if we should wait to have first ACID impl working
    jeff: can't we build a "fake" trivial protocol -  to provide a test 
bed for CF --
   mark: we do need a protocol to demo CF, would be nice to not delay 
acid work

AI on impl subteam --to produce proposal for a simple protocol for CF 
demo

Issue Discussion:


  http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=234
  Proposal: allow activity to change timeout for validity of context, 
when for example it wants to extend its validity. Potential problem is 
when the context is passed by value.
      1. Do we want to support this?
      2. Under what conditions would you be allowed to change the 
timeout?

  Is this worth the implementation overhead. What are the implications 
of changing a value in the context. Should this be legal, i.e. what 
parts of the context are immutable. Mark notes that we might want to 
add some language clarifying this, but it appears to him that the 
timeout is really the only value that makes sense to be mutable. Use 
case is one wants to extend a session without tearing down the session. 
Tony notes that in order for this capability to work, there has to be a 
way to communicate the change.

Greg: moves to close no action - dies lack of 2nd
Greg/mark: update spec to say that rules for changing timeout values is 
defined in  referencing specs.
     Mark: AI to investigate other mutability issues for other fields.
    Tony -- wants to define a method for changing the timeout -- Greg 
asks if set timeout only applies to factory at creation when context is 
being created, or if it could used anytime. Mark says the former, 
really its a set default timeout for creation of subsequent contexts.
     Note that if this proposal passes, we need to add an
Tony -- move to table, no second

vote - kevin, tony - no,  mark, martin, greg, simeone - yes 
doug-abstain -- passes

Mark/doug -- direct editors to add set timeout method to context 
service --
    greg -- wants to know what the impact this will have on existing 
e.g. tx protocols
    Motion withdrawn pending new AI on Mark to develop proposal.

Adjourned 9:00 am Pacific