OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: July F2F Draft Minutes


combined minutes attached  
WS-CAF meeting, Oracle, July 12 - 14 2004 morning
-------------------------------------------------------------------------
  

Role Call:
-------------

  Members:

	Mark Little
	Malik Saheb
	Tony Fletcher
	Peter Furniss
	Alastair Green
	Krishna Cheemalamarri
	Guy Pardon
	Eric Newcomer
	Martin Chapman
	Simeon Greene
	Jeff Mischkinsky
	Greg Pavlik
	Pete Wenzel
	Doug Bunting
	Ramesh Nagappan
	Jan Alexander

  Observers:

   Goran Olsson

Meeting is quorate until qurom counts requested. These have been clearly maked.

Agenda Review:
-----------------------

    http://www.oasis-open.org/apps/org/workgroup/ws-caf/event.php?event_id=4981


Minutes:
-----------

   Recommend adoption of June 21 minutes: http://www.oasis-open.org/archives/ws-caf/200406/msg00061.html
   Motion Passed


ACTION: Alistair to post minutes from July 5.

 

Issues List:
---------------
 

Issue 14. 

Discussion: Should be a consistency issue across specifications. Referencing specs would inherit from the base type. We need to define some conventions for handling definitions, and a consistent schema for hierarchically based specifications. We were going to allow the referencing specifications to define this and specify uniqueness, but we didn't carry it through consistently. We want unique status values, two proposals, one where we just use a namespace, and as Keith Swenson proposed you have a vanilla string with no namespace, but it's implicit in the string. Simeon prefers the namespace, as does Martin. Mark prefers using the namespace approach. But in the discussion it turns out that there's broken XML inasmuch as there's a value definition that needs to change but can't. So the Fujitsu approach seems more attractive in the end, with a generic string and the specification defining acceptable values. Could have a namespace attribute. 

Summary from Simeon after the discussion and whiteboard session:

Define a status type as a string, and it's up to the referencing specs to validate (i.e. values taken outside schema validation). Can have a namespace as an attribute on the status type for qualifying the values.  

 

Motion by Simeon, second by Malik:
Define a status type as an extension based on string in the schema. The value will not be defined in the schema but in the referencing specifications. There's an attribute on the types that specifies the namespace so the values can be uniquely qualified. 
 

Mark discussion: there's also the completed/completing status. If this solution is good for status, should the same solution be followed for completion status. 

Greg: completion status is an optional string in a message. 

Martin: Should be two different types but the same rules for each.

Greg: Do we really have different status types now for completed and the general status?

Mark: May be situations in which they are the same but other cases in which they have the same name but mean different things. 

Martin proposes a separate proposal about completing status - Mark agrees.

Motion carries, one negative vote. 
 

New Motion: Define an identical type for completion status.  Mark makes the motion, Malik seconds.

 Discussion? Tony - why do we need two? Mark: Happy enough with what Tony proposed - "completion command" instead of status for completion. 

Amendment to Mark's motion to define type for command instead of completion status. Completion status is now completion command but follows the same content model as status, which is a namespace-qualified string. 

Motion carries, one negative vote. 
[Can be a qname, in clarification to Doug, explanation of the morning's work.]

Issue 47

Still an action pending on Martin to discuss with Oracle security experts to get an idea for a proposal. 

 
Issue 59

should be closed since the specification doesn't use ALSes any more. 
Doug brings up Issue 58 - generally improving the diagrams.  But let's close Issue 59 first. 

Malik makes a motion to close issue 59 with no action. Tony seconds it.
No objections, motion carries. 

 

Issue 99
We need to do this but haven't the time at present. Leave open.

Assigned to editors. Need to discuss timeline as part of the general planning around document completion. 

On to Bryan Murray's issue list. Discussion includes Bryan and reviews changes in the editor's draft (0.4).

Martin: If the spec isn't unambiguous about the order of messages, something needs to be added. 

Greg sends editor's draft to the group for discussion, including comments/flags for Bryan's issues. 

We don't assume reliable messaging but it could be layered. Note that Mark's text qualifying Section 2.1 
about reliable messaging (Draft .04) is ok. 


Martin: Brian Murray [see .04 draft of WSCTX.doc] section 2.2] made a comment about the wsctx wsdl only being partially normative.  
The current context wsdl only mentions one-way messages.  Is that Normative?

Mark: In New Orleans we decided that the one-way messages would be normative and request-response would be for  a later version.

Martin: The spec should say “primarily uses one-way messages with callbacks”.

Greg Pavlik: Not primarily, but entirely... all the messages, operations and bindings are one-way style.

Martin: The specs should say “one-way operations with callbacks”.  This is prescriptive.  Other binding styles are possible, although they may have different acknowledgment styles and delivery mechanisms.

Martin: [section 1.3 of WSCTX.doc version 0.4] see comment mcl4-mcl6. Check with Greg who wrote this paragraph.

Greg: Figure numbers are incorrect... for example Figure 2 should be Figure 3.  The text that includes mcl4 should actually be a figure – figure 2.  Make sure the example is a coherent unit of text.

Martin: [reads mcl7 of WSCTX.doc version 0.4]  Regarding addressing spec.

Greg: [points to section 2.3] the spec intentionally does not specify how to do callbacks.

Martin: The spec needs to mention what assumptions are to be made with regards to addressing.

Martin: [reads mcl8 of WSCTX.doc version 0.4] who objected to this?

Mark: unique is unique... no need for “globally unique”.  

Eric: It's not necessary to say “globally unique”.

Martin: Votes to remove the phrase.

Doug: It's not the scope of uniqueness it's the scope of this particular id.

Martin: [clarifying Doug's point] the id's only needs to be unique in time?  Meaning it can be reused.

Greg: Uses a bank analogy to explain problems with reusing a unique id in any given time frame.  Ex.  The transaction id in a bank transaction should never really be reused.

Martin: Add a footnote or leave it.

Mark: Leave it.

[Vote: getting rid of “it must be globally unique”.  Result: carried (5 for, 1 abstain)]

Martin: [reads mcl10] If there are ordering dependencies they should be part of the description of the operations.  Action: Where an operation has dependencies, ex., a complete operation depending on a begin operation, it should be described in the spec.

Martin: [after some discussion] The behavior is undefined.  The client is free to do whatever it wants to do.  Action to the editors: put text into section 2.3 for unsolicited responses.

Martin: [reads mcl12]

Mark: This is addressed by the assumptions we addressed earlier in regards to reply-to.

Martin: Changing the context part of the primer.  Once we get the committee draft of the context spec we will change that section of the primer.

Doug Bunting: Explains problems currently experienced by WSRM's ServiceRefType.  WSRM wishes to add a bare uri element that is basically a fall-back that does not rely on any specific addressing specification.

Martin: Should our specs refer to the WSRM type (for ServiceRefType – see wsctx.xsd)?  The benefits would be that we wouldn't need to redefine the type.

Greg: But the base uri needed by wsrm is only needed for reliability semantics?

Doug: No.

Martin: Are we going to reference what WSRM is doing?

[discussion on the semantics of adding a bareUri element to ServiceRefType]

Martin: Revisit this for Aug 2nd conf call.

Martin: [section 5.2, 2nd sentence] “A begin can be modeled as the first Web service in the Activity to register itself.” 
Alistair: should be changed “A begin is therefore the first operation in an activity to use ws-context”.

[discussion of whether an activity is properly defined by the spec]

Morning

Reserved discussion for issues raised by Peter

136, 137, 138 about child contexts first.
Starting with 136: discussion of whether this should actually be the 
child contexts. Greg pointed out that specs may be in error. Alastair 
believes this is part of higher level protocol definition and is arguing 
that it doesn't belong in context: ancestral trail or tree reflecting 
children. Peter: concerned that typed field could be of the wrong type. 
Alastair: needs to be general to context. Eric: doesn't buy the 
argument: this is a general mechanism for representing nesting. Peter: 
doesn't think it should be reflected in the context. When nesting is 
occuring, are the fields sufficiently common. Eric: nice general 
purpose, in simple spec. Alastair: disagrees.

Setting up queue. Peter, Greg

Peter. Believes that 136, 137, and 138 would be answerable by reference 
to spec.
Greg: two points: we did go over use cases. Replication, security, 
transactions (we're all familiar with the latter); shouldn't we simply 
be validating structuring.
Eric: agrees with Greg

Peter is uploading file for 10 minute discussion

"Any construct whose semantic definition is only given in an extension 
specification should not be in the base". Somewhat analogous to 
polymorphism, but not quite. Greg: might this Context not be more like 
java.lang.String? Fully scoped, but semantics are applied with an 
application domain.

Context type: represented as struct.

Alastair: optional is a warning flag. Procedural motion to go issue 1 by 1.

Greg: schema doesn't supply normative rules. Alastair: what if text 
doesn't say optional. Greg:: needs to.

Moving on to 136. Peter on guiding principles. Martin: not sure slide 1 
is wholely clear. Alastair: number of ways to have baseness, so we have 
to be careful.

Mark: we voted to support nesting: shouldn't we just fix to reflect parents.

Alastair: nesting is ambigous. Martin: no it's not. Alastair: do we need 
to have the full tree? Doug: no, only a branch. Greg: by branch, you 
mean a fully directed path? Doug, yes. Martin: that's what shown. 
Alastair: ordering, partitioning, etc., implies a particular use. Why is 
this particular use being given preference?

Alastair: where do we need the whole tree: grid of network elements. 
Greg: I don't disagree, but we have concrete use cases. Why can't we 
support them? Alastair: have heard three views. Doug: Greg and I saying 
same thing. Peter:

Peter: Consider this hierarchy:

a
|
|--b--c
|    |--d
|--e

can you say for all possible contexts what this means? Can it cover 
arbitrary relationships?

Martin: this is only about parent-child relationships.

Alastair motion: remove child-contexts element from the context-type. 
Seconded by Peter. Discussion. Queue: Malik. Alastair. Mark. Eric. 
Ammendments can be proposed.

Malik: does motion mean that concept of nested activity is removed? 
Alastair: belongs in referencing spec. Malik: possibility to do nested 
activity should be present in context service. Would prefer to see 
parent context, but concept of nested activity should be removed. 
Alastair: believes example of why this should be removed. Believes that 
this will be a derived context service that understands nesting. It is a 
property of a higher level extension specification. May be many 
relationships. Shouldn't privilige one deemed relationship: you are 
trying to foresee all possible referencing specifications over time and 
selecting some subset. Believes basic notion of context is an identity 
of activities only.

Eric: believes useful and needs to be preserved but fixed. Generic 
infrastructure is useful. Ex. SOAP headers defined in advance of use.

Mark: proposal: The Context structure be changed to reflect parent child 
relationship whereby the child context is replaced by parent context 
(meant to represent current attribute name in context schema). Spec 
should be updated, to describe that this data structure only reflects a 
linear portion of a potentially tree like activity structure from the 
root to the leaf.

Alastair: point of order. Ammendment delete Alastair's and replace by.

Malik: second

Alastair: procedural motion: may be proposed as counterposed motions. 
Don't need charade.

Alastair: Mark meant to say from the leaf to the root. Doug: 
parenthetical: most narrow to most wide.

Mark ammends "from leaf to root".

Peter off queue: implicit but not stated about begin would fall away in 
original motion. Unclear that CF uses this mechanism. Is Mark proposing 
to revise this? Mark: reaction: change requires newly created activity 
to become the leaf and parent in hierarchy. Peter: should it put explict 
qualification on begin? Mark, is that not a separate issue. Peter, 
trouble is, answer effects how the relationship is understood by 
referening specification. If begin text says nothing, than this violates 
"Peter's first rule" from slidesets. In addition, presence or absence of 
field has no implication for how activities may be related (answering 
Malik).

Doug off queue: ammendment does a poor job of helping Doug understand 
how contexts of multiple types relate in a particular message. Spec is 
ambigous and suggests that there's a way to relate different activities. 
Original motion clarified relationship expression by removing them. Are 
activities in tree of the same type or different types? If different 
types, then nothing

Greg off queue: felt ammendment clarified (though I always assumed that 
Contexts of the same type). nesting is indeed a particular relationship, 
however it may be expressed as a general property as evidenced by the 
original definition of the context manager -- which worked in concert 
with the als. It is perhaps an implementation choice. Second: we want to 
express attributes of context, not just activity.

Goran: agrees with Peter's first slide "semantics that are unique to 
referencing specification should be defined there". Begin should define 
framework for creation. Believes context nesting belongs naturally in 
this specification as an artifact of context management.

Alastair: coordination framework relevant. Nesting relationships should 
be expressed via context.  Coordination framework tree is indepdent and 
does not make use. We have a mechanism artifially forced on referencing 
specification. Or mechanism isn't going to be used by CF. Do have 
specificity that cannot be distilled. Can remove begin, but points that 
functionality belongs in referencing specification. Believes that there 
is a latent desire to bag sets of contexts. Child context wasn't 
intended to do this. Doug: ambiguity in the text. Alastair believes 
there needs to be an statement that they need to be of the same type.

Martin: believes use cases for leaf to parent is useful enough.

Mark: no example for something other than parent child relationships. 
Other specs comparisons, txm and cf, is wrong because they were written 
against older version of specs with other assumptions.

Greg: tree building misleading. Modeling two things with indepdent 
semantics: nested activities, activity participants. Shouldn't conflate. 
Also reflects existing systems.

Eric: from discussion, we can agree that there is ambiguity.Believe we 
should fix spec not throw out

Doug: believe we need to say this is for a single type. Use cases so far 
has been for parent child. Havne't heard reason to have entire trail to 
root rather than immediate parent. What are the use cases for more than 
just parent. Eric, another ambiguity that should be resolved. Doug: may 
want to genericize proposal slightly. Proposing ammendment to 
ammendment: "only reflects some linear portion of a potentially tree 
like relationship between contexts of the same type".

Mark seconded it. Discussion. Does this mean parent only or parent up to 
root without saying "whole path". Doug: original proposal goes too far 
to specific solution. But reflects that we are talking about contexts of 
the same type.

Alastair: ammends ammendment to remove "only" then remove "linear 
portion of potentially tree like". Motivation: let's admit that 
referencing spec defines relationship. Peter second.

Malik: not clear about same type. Transactions nest transactions? Doug: 
two different types would be top level headers.

Martin: partially likes Dougs proposals.

Peter: can remove ambiguity which focuses it to a particular use. Do we 
want to reflect strict nesting. More precise, the less it belongs in 
base specs.

Eric: believes we have moved backward away from clarification. Likes 
Doug's clarification, not Alastair's.

Greg: would like to make motion to unwind.
Voting on ammendment to ammendment to ammendment to main motion. Ammendment voted down. 1 for, 7 against, 0 abstain.

Jeff has called question on Mark's ammendment. Also have to vote on 
ammendment to ammendment. No objections.
Alastair: clarification voting for, doesn't mean you agree on 
ammendment. 9 for, 1 abstention for Doug's.

Alastair: quorum call before next vote. Not quorate. Martin: proceed 
with recommendations to quorate group.

Vote, on marks ammended motion (child to parents). 7 yes. 2 against. 
ammendment carried.

Vote on motion as ammended. "Retaking same vote" for all intents and 
purposes; voting to change child to parent. 7 yes, 2 against. Net effect 
is what we recommend.

Martin motion to recess for lunch, come back at 1:30.

Minutes Tuesday July 13 2004 afternoon
 
13:00 Meeting resumes
 

Issue discussion continues..

 

Issue 136 - Use of begin with context and nested context needs more specification 

 

 

Discussion on the impact of previously accepted motion. 

 

Martin leads discussion. Will now reference parent context. There is no reference to siblings. Context will contain zero or one parent context. To get the hierarcho the whole

 

Motion: Change child context to be “parent context” 

Change parent context from list to zero or one occurrence and further change parents’ context to parent’s context. Alistair motioned Greg second. No opposed. 8 in favor.

 

Discussion on tree-building semantics. 

 

Motion by Mark: begin with passed context must set the parent context. 

Begin without passed context means no parent context is set. Malik second.

 

Alistair amendment to motion: delete begin with passed context. Tony second.

 

Vote: 2 in favor, 6, abstaining 1. Amendment did not pass.

 

Vote on Marks motion  6 for,  1 no, 1 abstained. Motion by Mark accepted.

 

This motion closes  issue 136.

 

 

 

Issue 138 - can a child context be separated from the parent

 

Closed as a result of previous motions.

 

Issue 137 - does dereferencing a context-by-reference always expand all child contexts 

 

Discussion

Peter: context manager can return what it pleases. 

Doug: the receiver needs to know what it gets.

Mark: begin return ref or value depending on implementation.

Alistair: spec should be silent on type.

Peter: getcontent return value must return value only.

 

Issue 137 parked until 133 is resolved.

 

Issue 133 - context by value and context by reference should be different types

 

Greg: no change from New Orleans.

Doug: ambiguous cases are few. 

Martin: by reference or value should be more like incomplete or complete information.

Doug: flipping back and forth between by reference and by value for a specific context is unnecessary. 

Alistair: Context manager is the only service that may change context value others can only observe.

 

Conclusion: leave issue open for time being to define final text that reflects the consensus. The consensus is basically: if context contains a context manager element then it can be dereferenced and when a context is dereferenced the whole known content of the context will be returned.

 

Action: Mark to produce text.

 

Back to Issue 137 - does dereferencing a context-by-reference always expand all child contexts 

 

Discussion.

Doug: Return context must be complete.

Alistair: getcontent should return what was set by setcontent. It should return what it knows.

Alistair: getcontent returns the entire known context

 

Leave dependent on  resolution of issue 133.

 

 

 

 

 

Issue 134 - mustUnderstand needs moving and defining

 

Related to 129

 

Ballot that previously closed 134 was about soap must understand.

Alistair: 134 should not have been closed.

 

Motion by Alistair to re-open 134. Second Mark.

No objections. Issue 134 is re-opened. 

 

BREAK.

 

15:00 Meeting resumes

 

Issue 135 - participating-services list needs to have defined semantics and modification mechanisms or be removed 

 

Discussion.

Greg: what is a participating service?

Alistair: Not clear.

Eric: the purpose was for a minimal protocol as part of the specification. Now that is handled by referencing specifications. 

Peter:

Motion by Eric; since we have extention point. I suggest we remove the participating service list. 

Peter second.

No objections. Motion approved. Close issue 135.

 

Issue 140
 

Discussion

Alistair: if we use context manager element is not part of this issue.

Martin : how do we use this URL.

Peter: reading from note .4 

 

Motion by Alistair: remove the context URI leaving the context manager as the sole choice.

Greg second.

Discussion.

Eric: a clarification there is now two emerging specifications around. We need to allow for adoption of either.

 Vote: 7 for, 0 against, 0 abstained. Motion accepted.

Issue 140 closed by adopting motion.

 

Issue 141 is dependent on 133. To be discussed once new 133 text is available.

 

Issue 142 
 

Discussions.

Alistair: there are multiple questions.

Motion by Simeon: change the type of context service from any type to a service reference Type.

Malik second.

 

Alisair motion to table discussions. Peter second.

Table 2 for, 5 against.

Alistair: the notion of status and the way protocols complete is purely related to referencing specifications. I support having the reference available to query about state. 

Even though state would be defined by referencing specifications.

Eric: Speaks in favor of the motion. 

 

Objections none. Motion accepted.

 

Motion by Alistair: make context service field mandatory.

Simeon second.

 

Vote no in favor, 5 against, 1 abstained. Motion failed. Field remains optional.

  

Ad-hoc discussion on the relevance having a completing state. Alistair argues that it will never be observed, instead a transitional state defined in the referencing specification 

will be observed.  

 

Consensus: the state active, completing, and completed are important for a modeling purpose.

 

Action: Alistair to define the relevance of querying state while the activity is in

Between active and completed state, the “completing” state.



Issue 134 again.

 

Motion by Peter: to remove any references that WSCTX must understand from the context type structure.

Second Alistair.

 

No objections. Motion accepted. This motion closes issue 134.

 

16:30 Demo presentation showing interoperable implementations starts. 

 

Presented by Simeon. Slides at: 
 

Discussion followed about the value of the demo to showcase context services.

The demo was deemed a valuable

Several suggestions were made to improve the demo.

 

Chair recaps work. Schedule is on track.

 

17:15 motion to recess until Wednesday 9:00.

Some pre-meeting agenda bashing, what will be the most effective way of getting started on ws-cf, especially given the changes to ws-context.
 

Logistics/ws-context schedule:
 
We've had a successful meeting - need to have another go-round, editors' draft, review
 
There is still an issue-to-be-submitted from Alastair. To be put on agenda for next phone meeting.
 
Martin suggests a target for a document for vote in first week Sept
Alastair - need to have the text 2 weeks before a vote
 
Martin: intended category of this document - committee draft would seem appropriate
 
current meetings schedule: 
 
various patterns of drafts considered. Conclusion:

No call on 19th July.
 
2 August: submit and resolve all outstanding independent issues (addressing issue/alignment with ws-rel may still be open)
  (meeting confined to context matters only)
 
9 August: circulate 0.5 draft containing all issue resolutions
 
(from now till circulation of voteable, all are expected to carefully review the draft and submit editorial comments,
editors polish text to produce draft to vote for CD)
 
16 August - normal meeting
 
23 August: circulate candidate draft
 
30 August: - normal meeting; initiate vote to approve candidate as Committee Draft
 
6 Sept: (7 days from vote opening) vote concludes
 

Next face-to-face:
 
Possibles:
 Brussels - OASIS plenary week - October 4th.
 Prague - same week
 Dublin - same week
 
Prague chosen
 
timings considered:
 4, 5th all day
 4 pm, 5, 6 am
 5,6 all day
 
preference vote of those attending here:
 
Conclusion: 5th, 6th,all day
 
Further out:  dec/jan, probably east coast (oracle mt laurel ?)
  (pattern up to then: Boston, Paris, New Orleans, San Francisco, Prague )
  
  
2. Coordination Framework
 
How to bootstrap work.
 
Martin: WS-context has changed, and there is a need for a revision of it
Also need to have general discussion on model and cf as a whole
 
Greg - things are simpler now
 
before:
 
 client/app   <-> context service  <->  als
  
   this had problems on the cs:als interactions, what had to be kept
   
   cf was defined as an als - als is also a cf, so cs:als/cf interactions had 
   to be dealt with
   
 
 complete to cs with cf - there is a registration exchange that allows
 communication through the tree (though its up to the coord pcol whether
 that is used)
 
after: (i.e. now, post NO)
 
 c/a  <->  context service, how does cf 
 
 how to the express cs : cf relationship
 
 what was an als is now in a sort of inheritance relationship on cs
 
 ag: could use the cs mechanisms, extended/overloaded to tree build (the begin+context)
   but with cf it's suggested that a different tree building mechanism is used
 
 greg: not the way existing transaction systems work - nesting is tied to demarcation api, enlistment is internal/invisible
 
 the discussion continued
 
 greg, martin: distinction between relationship between participants and relationship between activities.
 
 participants are members of an activity
 sub-activities (nested a) are a particular kind of participant
 
 ag: consider a tree of things
  and interposition
  
  addParticipant builds trees. these could (but need not) load the parent-context fields. If they do and begin+context is used as well, then we have two ways of tree building - or there is another way of holding the trace
  
 Martin: depends on type of thing added - use one if it is an activity, addP if not
 
 alastair: as with WS-C,  cf doesn't currently allow general tree building, with no hierarchy. Dynamic commit (as the general movement of the coordination point)
 
 also can't have differential coordinate to subsets of participants
 
 WS-C doesn't have the "active" parts that are in ws-cf - only the tree building (registration, address exchange). this is a better split of responsibility - the higher specification should be responsible for the demarcation, completion and coordination signals
 
 a tree-building p'col is useful.
 
 greg: context has virtue as activity concept, apart from tree-building
 
 activity has lifecycle characteristics - they begin, they run, they complete 
  
 martin: if we make ws-cf not use begin, complete etc, and only use the context, then we've messed up
 
 greg: we can extend these, cf adds semantics to the ws-ctx begin, complete
 

 alastair:  e.g. dynamic commit wouldn't use coordinate or complete - the completion of the transaction uses other signals.
   consider also an upcoming cancel (greg: or timeout expiry) which would also cause completion
   
 greg: what proportion of higher specs would NOT use complete etc.
 
 martin: no point in a generic mechanism that nothing uses.
 
Choreology list of issues.
 
Martin can choreology put these into bugzilla ?
 
Better to treat these as inputs to the editors revision /alignment of the ws-cf specs.
 
Editors: take into account the choreology comments as part of the revision of the ws-cf to align with the changes in ws-context.  Some of the comments may survive this and then should be entered as issues proper.
 
Back to cf concepts.
 
greg: asks alastair if e.g. open-top 2pc pcols can't be supported by cf/ctx
 
alastair: can be supported, but would be constrained or have to re-write the rules for e.g. complete
 
...
could have overloading of coordinate, complete, which in some cases triggered the underlying complete message/signal
 

Martin: would like to see an analysis of the known candidates (txm's 3, btp, ws-tx's 2) and whether they would use/be comfortable with the ws-ctx complete, ws-cf coordinate. Impact on ws-ctx complete and ws-ctx timetable.
try and get some finger-in-the-air as to whether the use of these is never, rare, common, usual, always.
 Informal action point: omnes/volunteer
 
Motion to adjourn:  12:10 pdt.












[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]