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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote


In my view, there are only two positions that can be taken here. Either we admit that races are bad and we do something to rule them out, including any existing ones (either by static analysis, or by clearly stating in the spec that the language cannot prevent them and their occurrence at run time makes the process behavior unpredictable).

Or we say that races are ok, including the issue 81 proposal.

Your position seems to be something like the following: races are bad, but let's keep quiet about them, and let's not make the problem even more evident by introducing something like the issue 81 proposal. I prefer instead to address the races problem head-on, if we believe that indeed it is a problem, or otherwise simply allow races to occur anywhere in the language.

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com] 
> Sent: Monday, September 13, 2004 10:18 PM
> To: ygoland@bea.com; Ugo Corda
> Cc: wsbpeltc
> Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> 
> 
> Yaron,
>  
> You probably did not have time to read the thread thoroughly. 
>  For instance, I wrote below:
>  
> >  > > I repeat.  There are races that can be detected and 
> ones that  > 
> > > cannot.  Your example is not a race.  Non-start receives 
> that  > > 
> > depend on correlation initiated by a start receive do create  > > a 
> > race.  I am concerned about going out of our way to allow  > > 
> > something that clearly is a race.
> 
> I agree that all races cannot be eliminated, although the one 
> you showed can in fact be detected.  I am not asking for 
> static analysis to eliminate all races pessimistically.  I am 
> simply asking why we should clarify something in a way that 
> almost perversely creates a race.  Nothing very profound 
> (sorry to disappoint you :-)).
>  
> Satish
> 
> ________________________________
> 
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Mon 9/13/2004 2:44 PM
> To: Ugo Corda
> Cc: Satish Thatte; wsbpeltc
> Subject: Re: [wsbpel] Issue 81 - Rough draft of proposal for vote
> 
> 
> 
> I must admit that I don't understand the point that Satish is 
> making. I believe he is arguing that we shouldn't allow for 
> situations that could contain race conditions but just about 
> all messaging situations can potentially enable race conditions.
> 
> I've tried to boil the situation down as far as I can. Below 
> I provide two examples that are different only in that one 
> has a flow and another has a sequence. In so far as I'm 
> concerned these two scenarios are absolutely identical in 
> terms of their ability to cause race conditions and therefore 
> there is no need to distinguish between them. I believe that 
> Satish disagrees but I don't understand why. Hopefully he can 
> use these two very specific examples to explain himself in a 
> manner that even my intellect can grasp.
> 
> scope
>     flow
>        receive ... createInstance="yes"
>           correlations
>              correlation set="foo" initiate="yes"
>        receive ... createInstance="no"
>           correlations
>              correlation set="foo" initiate="no"
> 
> and
> 
> scope
>     sequence
>        receive ... createInstance="yes"
>           correlations
>              correlation set="foo" initiate="yes"
>        receive ... createInstance="no"
>           correlations
>              correlation set="foo" initiate="no"
> 
> 
>         Thanks,
> 
>                         Yaron
> 
> 
> Ugo Corda wrote:
> 
> >
> >
> > Actually a correlation set is far from being a GUID. A GUID 
> is unique 
> > and it implies that the initiator generates it and any 
> follower would 
> > only know it after receiving it from the initiator. But correlation 
> > sets are just business data (e.g. customer ID) which all 
> the parties 
> > might very well know since the beginning. That is what does not 
> > prevent a sender, in my mind, from sending a message to the 
> receive at 
> > the same time as the invoke is launched.
> >
> > Section 10.1 implies temporal sequence for what concerns activities 
> > invocation, but it does not say anything, as far as I can 
> see, about 
> > timing of message sending.
> >
> > And as far as timing of activity invocation is concerned, 
> in the flow 
> > case with two receives, the start receive is necessarily activated 
> > first (without that activation, the second receive does not even 
> > exist), and it is only after that activation (and related 
> setting of 
> > the correlation
> > set) that the non-start receive is activated. So, again, not that
> > different than the invoke/receive sequence.
> >
> > Ugo
> >
> >  > -----Original Message-----
> >  > From: Satish Thatte [mailto:satisht@microsoft.com]
> >  > Sent: Friday, September 10, 2004 4:07 PM
> >  > To: Ugo Corda; ygoland@bea.com
> >  > Cc: wsbpeltc
> >  > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal 
> for vote  
> > >  >
> >  > The assumption underlying the correlation mechanism is that
> >  > it is like a "header" with a "correlation GUID" similar to a
> >  > session ID.  Thus the correlation tokens are created by some
> >  > one party in the correlated conversations.  In particular by
> >  > the party that has a send with initiate=true.  The
> >  > "initiator" of the correlation.  The others are called
> >  > "followers".  See section 10.1.
> >  >
> >  > -----Original Message-----
> >  > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >  > Sent: Friday, September 10, 2004 3:57 PM
> >  > To: Satish Thatte; ygoland@bea.com
> >  > Cc: wsbpeltc
> >  > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> >  >
> >  > Sorry, I still do not see the difference. I think you are
> >  > using a different set of assumptions than I do. In
> >  > particular, I don't understand your statement below: "the
> >  > invoke must complete all the way to its target before the
> >  > message corresponding to the receive can even be sent, since
> >  > the correlation tokens must be copied into it". What prevents
> >  > a sender from sending a message to the receive, with the same
> >  > correlation set as defined by the invoke, before the invoke
> >  > itself completes, or even at the same exact time that the
> >  > invoke initiates? Couldn't that message be lost in that case too?
> >  >
> >  > Ugo
> >  >
> >  > > -----Original Message-----
> >  > > From: Satish Thatte [mailto:satisht@microsoft.com]
> >  > > Sent: Friday, September 10, 2004 2:48 PM
> >  > > To: Ugo Corda; ygoland@bea.com
> >  > > Cc: wsbpeltc
> >  > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
> proposal for vote
> >  > >
> >  > >
> >  > > The difference is that the message which instantiates the
> >  > > instance and initiates the correlation arrives simultaneously
> >  > > with the non-start one which is dependent on the correlation.
> >  > >  Note that the start message is not dependent on the
> >  > > correlation hence will not be lost regardless of how slow
> >  > > instantiation is.  The non-start message may be lost.
> >  > >
> >  > > This is distinct from the example below where the correlation
> >  > > initiation is always before the dependent activity, and in
> >  > > fact the invoke must complete all the way to its target
> >  > > before the message corresponding to the receive can even be
> >  > > sent, since the correlation tokens must be copied into it.
> >  > >
> >  > > I repeat.  There are races that can be detected and ones that
> >  > > cannot.  Your example is not a race.  Non-start receives that
> >  > > depend on correlation initiated by a start receive do create
> >  > > a race.  I am concerned about going out of our way to allow
> >  > > something that clearly is a race.
> >  > >
> >  > > -----Original Message-----
> >  > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >  > > Sent: Friday, September 10, 2004 2:12 PM
> >  > > To: Satish Thatte; ygoland@bea.com
> >  > > Cc: wsbpeltc
> >  > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
> proposal for vote
> >  > >
> >  > > > In your example, there is no race if the invoke is 
> initiating the
> >  > > > correlation that the other party is using for the receive.
> >  > >
> >  > > Same with the two initial receive's within a flow. The start
> >  > > receive initiates the correlation and the non-start receive
> >  > > can use that correlation.
> >  > >
> >  > > Ugo
> >  > >
> >  > > > -----Original Message-----
> >  > > > From: Satish Thatte [mailto:satisht@microsoft.com]
> >  > > > Sent: Friday, September 10, 2004 2:02 PM
> >  > > > To: Ugo Corda; ygoland@bea.com
> >  > > > Cc: wsbpeltc
> >  > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
> proposal for vote
> >  > > >
> >  > > >
> >  > > > In your example, there is no race if the invoke is 
> initiating the
> >  > > > correlation that the other party is using for the receive.
> >  > > >
> >  > > > But in general, as I said, there are races that can be
> >  > detected and
> >  > > > ones that cannot.  I am simply concerned about going out
> >  > of our way
> >  > > > to allow something that clearly is a race.
> >  > > >
> >  > > > -----Original Message-----
> >  > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >  > > > Sent: Friday, September 10, 2004 12:07 PM
> >  > > > To: Satish Thatte; ygoland@bea.com
> >  > > > Cc: wsbpeltc
> >  > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
> proposal for vote
> >  > > >
> >  > > > The following is also statically detectable:
> >  > > >
> >  > > > sequence
> >  > > >   invoke
> >  > > >   receive
> >  > > > sequence
> >  > > >
> >  > > > Depending on the time spent executing the invoke, the receive
> >  > > > message might be lost. So are we going to disallow 
> that type of
> >  > > > sequence too?
> >  > > >
> >  > > > Ugo
> >  > > >
> >  > > > > -----Original Message-----
> >  > > > > From: Satish Thatte [mailto:satisht@microsoft.com]
> >  > > > > Sent: Friday, September 10, 2004 11:55 AM
> >  > > > > To: ygoland@bea.com; Ugo Corda
> >  > > > > Cc: wsbpeltc
> >  > > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> >  > proposal for vote
> >  > > > >
> >  > > > >
> >  > > > > I have a sense of déjà vu that I have seen this and
> >  > replied to it
> >  > > > > earlier.
> >  > > > >
> >  > > > > Basically, the answer is that it is possible to 
> make process
> >  > > > > protocol mistakes that would cause races that would then
> >  > > risk losing
> >  > > > > messages.  Not all such races can be statically detected.
> >  > >  However,
> >  > > > > non-start initial receives (assuming they are appropriately
> >  > > > > correlated) are an obviously statically detectable case,
> >  > > hence there
> >  > > > > is no reason to allow them.
> >  > > > >
> >  > > > > -----Original Message-----
> >  > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com]
> >  > > > > Sent: Friday, September 10, 2004 10:54 AM
> >  > > > > To: Ugo Corda
> >  > > > > Cc: Satish Thatte; wsbpeltc
> >  > > > > Subject: Re: [wsbpel] Issue 81 - Rough draft of
> >  > proposal for vote
> >  > > > >
> >  > > > > I agree with Ugo. I don't see the difference. What makes it
> >  > > > > 'explicitly impossible' to expect that such a message
> >  > > would arrive?
> >  > > > > In fact, how is
> >  > > > > it any different than a start receive immediately 
> followed by a
> >  > > > > non-start receive? The behavior in the BPEL sense would
> >  > > > > appear to me to
> >  > > > > be identical.
> >  > > > >
> >  > > > >         Thanks,
> >  > > > >
> >  > > > >                 Yaron
> >  > > > >
> >  > > > > Ugo Corda wrote:
> >  > > > >
> >  > > > > >
> >  > > > > >
> >  > > > > >  > Yes except in the latter case we have some
> >  > > expectation of a  >
> >  > > > > > protocol to make sure messages don't arrive too early.
> >  > > > > >
> >  > > > > > I cannot see the difference. The activation of a
> >  > > > > non-initial receive
> >  > > > > > is dependent on the completion of the preceding
> >  > > activities in the
> >  > > > > > sequence, which can be completely run-time dependent. The
> >  > > > > activation
> >  > > > > > of an initial non-start receive is dependent on the
> >  > > > > reception of the
> >  > > > > > initial start receive, which can also be 
> completely run-time
> >  > > > > > dependent. I don't see how any protocol could do better
> >  > > > in one case
> >  > > > > > than in the other.
> >  > > > > >
> >  > > > > > Ugo
> >  > > > > >
> >  > > > > >  > -----Original Message-----
> >  > > > > >  > From: Satish Thatte [mailto:satisht@microsoft.com]
> >  > > > > >  > Sent: Tuesday, August 31, 2004 10:15 AM
> >  > > > > >  > To: Ugo Corda; ygoland@bea.com
> >  > > > > >  > Cc: wsbpeltc
> >  > > > > >  > Subject: RE: [wsbpel] Issue 81 - Rough draft 
> of proposal
> >  > > > > for vote
> >  > > > > > >  >
> >  > > > > >  > Yes except in the latter case we have some
> >  > > expectation of a  >
> >  > > > > > protocol to make sure messages don't arrive too early.
> >  > > In  > the
> >  > > > > > initial non-start receive this is explicitly
> >  > > impossible.  > I am
> >  > > > > > just saying that we can interpret this at a technical  >
> >  > > > level but I
> >  > > > > > wonder if it is really meaningful. Not a huge  > 
> deal but my
> >  > > > > > preference is to tighten the features so we can  >
> >  > > justify their
> >  > > > > > usage.  >
> >  > > > > >  >
> >  > > > > >  > -----Original Message-----
> >  > > > > >  > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >  > > > > >  > Sent: Tuesday, August 31, 2004 10:10 AM
> >  > > > > >  > To: Satish Thatte; ygoland@bea.com
> >  > > > > >  > Cc: wsbpeltc
> >  > > > > >  > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> >  > > > proposal for vote
> >  > > > > >  >
> >  > > > > >  > I imagine that would be not different than 
> the case of a  >
> >  > > > > > non-initial receive to which a message is sent 
> before the  >
> >  > > > > > receive itself is activated. It would be up to the  >
> >  > > > > > implementation to decide whether to cache the message
> >  > > > or drop it.
> >  > > > > >  >
> >  > > > > >  > Ugo
> >  > > > > >  >
> >  > > > > >  > > -----Original Message-----
> >  > > > > >  > > From: Satish Thatte 
> [mailto:satisht@microsoft.com]  > >
> >  > > > > > Sent: Tuesday, August 31, 2004 9:40 AM  > > To: 
> Ugo Corda;
> >  > > > > > ygoland@bea.com  > > Cc: wsbpeltc
> >  > > > > >  > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> >  > > > > proposal for vote
> >  > > > > >  > >
> >  > > > > >  > >
> >  > > > > >  > > Suppose such an activity is a receive.  How would
> >  > > > the message
> >  > > > > > > > be correlated to the instance without danger of being
> >  > > > lost if  >
> >  > > > > > > it arrived "too soon"?  > >
> >  > > > > >  > >
> >  > > > > >  > > -----Original Message-----
> >  > > > > >  > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >  > > > > >  > > Sent: Tuesday, August 31, 2004 9:31 AM
> >  > > > > >  > > To: Satish Thatte; ygoland@bea.com
> >  > > > > >  > > Cc: wsbpeltc
> >  > > > > >  > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> >  > > > > proposal for vote
> >  > > > > >  > >
> >  > > > > >  > > It would probably be easier if you could explain why
> >  > > > those  > >
> >  > > > > > activities should be banned. What kind of problems do you
> >  > > >  > > think
> >  > > > > > they would create?  > >
> >  > > > > >  > > Ugo
> >  > > > > >  > >
> >  > > > > >  > > > -----Original Message-----
> >  > > > > >  > > > From: Satish Thatte
> >  > > [mailto:satisht@microsoft.com]  > > >
> >  > > > > > Sent: Monday, August 30, 2004 10:47 PM  > > > 
> To: Ugo Corda;
> >  > > > > > ygoland@bea.com  > > > Cc: wsbpeltc
> >  > > > > >  > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> >  > > > > proposal for vote
> >  > > > > >  > > >
> >  > > > > >  > > >
> >  > > > > >  > > > Help me understand why we should allow initial
> >  > > > non-start  >
> >  > > > > > activities?  > > > Why not ban those?
> >  > > > > >  > > >
> >  > > > > >  > > >
> >  > > > > >  > > > -----Original Message-----
> >  > > > > >  > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> >  > > > > >  > > > Sent: Friday, August 27, 2004 8:04 PM
> >  > > > > >  > > > To: ygoland@bea.com
> >  > > > > >  > > > Cc: wsbpeltc
> >  > > > > >  > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of
> >  > > > > proposal for vote
> >  > > > > >  > > >
> >  > > > > >  > > > Your new wording works for me!
> >  > > > > >  > > >
> >  > > > > >  > > > Thank you,
> >  > > > > >  > > > Ugo
> >  > > > > >  > > >
> >  > > > > >  > > > > -----Original Message-----
> >  > > > > >  > > > > From: Yaron Y. Goland
> >  > [mailto:ygoland@bea.com]  > > > >
> >  > > > > > Sent: Friday, August 27, 2004 3:39 PM  > > > > 
> To: Ugo Corda
> >  > > > > >  > > > > Cc: wsbpeltc
> >  > > > > >  > > > > Subject: Re: [wsbpel] Issue 81 - Rough 
> draft of  >
> >  > > > > > proposal for vote  > > > >
> >  > > > > >  > > > >
> >  > > > > >  > > > > An excellent point. So long as we require
> >  > that all  >
> >  > > > > > processes MUST  > > > > have at least one start 
> activity then
> >  > > > > > initial
> >  > > > > activities can be
> >  > > > > >  > > > > anything.
> >  > > > > >  > > > >
> >  > > > > >  > > > > Below is my modified rough draft of a proposal
> >  > > > to vote:  >
> >  > > > > > > > >  > > > > Section 6.4
> >  > > > > >  > > > >
> >  > > > > >  > > > > Change: To be instantiated, each business
> >  > > process must  >
> >  > > > > > contain at  > > > > least one such "start activity."
> >  > > This must be
> >  > > > > > an initial  > > activity in
> >  > > > > >  > > > > the sense that there is no basic activity that
> >  > > logically
> >  > > > > >  > > precedes it
> >  > > > > >  > > > > in the behavior of the process.
> >  > > > > >  > > > >
> >  > > > > >  > > > > To: To be instantiated, each business
> >  > process must  > >
> >  > > > > > contain at least  > > > > one such "start activity."
> >  > That is, a
> >  > > > receive/pick activity
> >  > > > > >  > > > > annotated with a createInstance="yes"
> >  > > attribute. See  >
> >  > > > > > section 11.4  > > > > for more details on start
> >  > activities.  > >
> >  > > > > > > >  > > > > Section 11.4
> >  > > > > >  > > > >
> >  > > > > >  > > > > Change: A receive activity annotated in this
> >  > > way MUST be
> >  > > > > >  > > an initial
> >  > > > > >  > > > > activity in the process, that is, the only
> >  > other basic
> >  > > > > > > activities  > > > > may potentially be performed
> >  > prior to or
> >  > > > > > simultaneously  > > with such a
> >  > > > > >  > > > > receive activity MUST be similarly annotated
> >  > > > > receive activities.
> >  > > > > >  > > > >
> >  > > > > >  > > > > To: A receive/pick activity annotated in this
> >  > > > way MUST be
> >  > > > > > > > a "start  > > > > activity". A "start activity" is
> >  > > an initial
> >  > > > > activity that has a
> >  > > > > >  > > > > createInstance="yes" attribute defined on it. An
> >  > > > initial  >
> >  > > > > > > activity is  > > > > a receive/pick activity 
> where no other
> >  > > > > > activities but  > > scope, flow,
> >  > > > > >  > > > > sequence and empty activities occur before it in
> >  > > > > the process's
> >  > > > > >  > > > > execution path. While all start activities must
> >  > > > be initial
> >  > > > > > > > > > activities not all initial activities 
> are required
> >  > > > > to be start
> >  > > > > >  > > > > activities. If
> >  > > > > >  > > > an initial
> >  > > > > >  > > > > activity is not a start activity then the
> >  > > > initial activity
> >  > > > > > > > > will only  > > > > become active when it 
> is inside of a
> >  > > > > > process instance.  > > > >
> >  > > > > >  > > > > Change: It is permissible to have the
> >  > > createInstance  > >
> >  > > > > > attribute set  > > > > to "yes" for a set of
> >  > concurrent initial
> >  > > > > > activities.  > > > >
> >  > > > > >  > > > > To: It is permissible to have multiple start
> >  > > activities.
> >  > > > > >  > > > >
> >  > > > > >  > > > > Change: All such receive activities MUST use
> >  > the same
> >  > > > > > > correlation  > > > > sets (see Correlation).
> >  > > > > >  > > > >
> >  > > > > >  > > > > To: If a process has multiple start
> >  > activities then all
> >  > > > > >  > the start
> >  > > > > >  > > > > activities MUST use the same 
> correlation sets (see
> >  > > > > >  > > > Correlation).
> >  > > > > >  > > > >
> >  > > > > >  > > > > Ugo Corda wrote:
> >  > > > > >  > > > >
> >  > > > > >  > > > > >
> >  > > > > >  > > > > >
> >  > > > > >  > > > > >  > and only receive/pick in
> >  > > > > >  > > > > >  > addition to the previously listed
> >  > > > activities MAY occur
> >  > > > > >  > > > > in parallel
> >  > > > > >  > > > > > with  > it in the process's execution
> >  > path.  > > > >
> >  > > > > > >  > > > > > Why limit it to other receive/pick
> >  > > activities? If the
> >  > > > > > > > following is  > > > > > allowed
> >  > > > > >  > > > > >
> >  > > > > >  > > > > > <flow>
> >  > > > > >  > > > > >       <receive createInstance="yes".../>
> >  > > > > >  > > > > >       <receive createInstance="no".../>
> >  > > > > >  > > > > > </flow>
> >  > > > > >  > > > > >
> >  > > > > >  > > > > > then why not also allow this:
> >  > > > > >  > > > > >
> >  > > > > >  > > > > > <flow>
> >  > > > > >  > > > > >       <receive createInstance="yes".../>
> >  > > > > >  > > > > >       <invoke .../>
> >  > > > > >  > > > > > </flow>
> >  > > > > >  > > > > >
> >  > > > > >  > > > > >
> >  > > > > >  > > > > > Ugo
> >  > > > > >  > > > > >
> >  > > > > >  > > > >
> >  > > > > >  > > >
> >  > > > > >  > > > To unsubscribe from this mailing list (and be
> >  > > > > removed from the
> >  > > > > >  > > > roster of the OASIS TC), go to
> >  > > > > >  > > >
> >  > > > > 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> >  > > > > >  > > ave_workgr
> >  > > > > >  > > oup.php.
> >  > > > > >  > >
> >  > > > > >  > >
> >  > > > > >  > > To unsubscribe from this mailing list (and be
> >  > > > removed from  > >
> >  > > > > > the roster of the OASIS TC), go to  > >
> >  > > > > > 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> >  > > > > >  > ave_workgr
> >  > > > > >  > oup.php.
> >  > > > > >  >
> >  > > > > >  >
> >  > > > > >  > To unsubscribe from this mailing list (and be removed
> >  > > > from  > the
> >  > > > > > roster of the OASIS TC), go to  >
> >  > > > > > 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> >  > > > > > ave_workgr
> >  > > > > > oup.php.
> >  > > > > >
> >  > > > >
> >  > > >
> >  > > > To unsubscribe from this mailing list (and be 
> removed from the
> >  > > > roster of the OASIS TC), go to
> >  > > > 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> >  > > ave_workgroup.php.
> >  > >
> >  > >
> >  >
> >
> 
> 
> 


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