sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Proposed resolution to BINDINGS-85
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Bindings" <sca-bindings@lists.oasis-open.org>
- Date: Mon, 21 Sep 2009 12:43:16 +0100
Folks,
I agree with Anish - keep the normative
statements to the minimum and simply provide informative
documentation of any known conflicts.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| Anish Karmarkar <Anish.Karmarkar@oracle.com>
|
To:
| Eric Johnson <eric@tibco.com>
|
Cc:
| David Booz <booz@us.ibm.com>,
sca-bindings@lists.oasis-open.org
|
Date:
| 17/09/2009 07:30
|
Subject:
| Re: [sca-bindings] Proposed resolution
to BINDINGS-85 |
Eric Johnson wrote:
> Hi Dave,
>
> I agree that calling out the explicit conflict is a good idea. I
guess
> my question is whether we get any value from an additional normative
> statement?
I tend to think that we should document the known conflicts and just
point to the Policy normative statement in the binding spec.
-Anish
--
>
> -Eric.
>
> David Booz wrote:
>>
>> Maybe, it depends on how the reader might interpret the meaning
or
>> purpose of the various intents and config options. We had an
>> interesting debate on the meaning of delivery-mode. I still see
value
>> in being explicit about conflicts that we know about. If there
are
>> others we should get those addressed as well.
>>
>> Dave Booz
>> STSM, BPM and SCA Architecture
>> Co-Chair OASIS SCA-Policy TC and SCA-J TC
>> "Distributed objects first, then world hunger"
>> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
>> e-mail:booz@us.ibm.com
>>
>> Inactive hide details for Eric Johnson ---09/14/2009 02:32:42
PM---Hi
>> Dave If that's the case, isn't the other normative stateEric Johnson
>> ---09/14/2009 02:32:42 PM---Hi Dave If that's the case, isn't
the
>> other normative statement equally redundant?
>>
>>
>> From:
>> Eric Johnson <eric@tibco.com>
>>
>> To:
>> David Booz/Poughkeepsie/IBM@IBMUS
>>
>> Cc:
>> sca-bindings@lists.oasis-open.org
>>
>> Date:
>> 09/14/2009 02:32 PM
>>
>> Subject:
>> Re: [sca-bindings] Proposed resolution to BINDINGS-85
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hi Dave
>>
>> If that's the case, isn't the other normative statement equally
redundant?
>>
>> More below.
>>
>> David Booz wrote:
>>
>> Eric,
>>
>> There's this from the
policy FW spec:
>>
>> If the configured instance
of a binding is in conflict
>> with the intents and
policy sets selected for that
>> instance, the SCA runtime
MUST raise an error. [POL30001].
>>
>> It's the very first
normative statement in the spec.
>>
>> I guess that's proof enough that I really, really, really, haven't
>> read it!
>>
>> I don't think we need
your second normative statement below.
>>
>> Agreed.
>>
>> -Eric.
>>
>>
>> Dave Booz
>> STSM, BPM and SCA Architecture
>> Co-Chair OASIS SCA-Policy
TC and SCA-J TC
>> "Distributed objects
first, then world hunger"
>> Poughkeepsie, NY (845)-435-6093
or 8-295-6093_
>> __e-mail:booz@us.ibm.com_
<mailto:e-mail:booz@us.ibm.com>
>>
>> Inactive hide details
for Eric Johnson ---09/14/2009
>> 01:38:20 PM---Hi Simon,
I like the proposal, but I'm
>> wondering whether thEric
Johnson ---09/14/2009 01:38:20
>> PM---Hi Simon, I like
the proposal, but I'm wondering
>> whether the text at
the end is singling out the pa
>>
>> From:
>> Eric Johnson _<eric@tibco.com>_
<mailto:eric@tibco.com>
>>
>> To:
>> Simon Holdsworth _<simon_holdsworth@uk.ibm.com>_
>> <mailto:simon_holdsworth@uk.ibm.com>
>>
>> Cc:
_
>> __sca-bindings@lists.oasis-open.org_
>> <mailto:sca-bindings@lists.oasis-open.org>
>>
>> Date:
>> 09/14/2009 01:38 PM
>>
>> Subject:
>> Re: [sca-bindings] Proposed
resolution to BINDINGS-85
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hi Simon,
>>
>> I like the proposal,
but I'm wondering whether the text at
>> the end is singling
out the particular policy intent
>> "atLeastOnce",
when, in fact, a more general statement
>> applies - for example,
transaction intents, or vendor
>> defined intents that
might conflict with a JMS configuration.
>>
>> That is, something more
like this:
>>
>> This specification does
not define a fixed relationship
>> between any intents
or combination thereof, and a
>> particular configuration
of a JMS binding. For example,
>> this specification does
not define any relationship
>> between reliability
intents and the persistence of JMS
>> messages. Deployers/assemblers
can configure
>> NON_PERSISTENT for @deliveryMode
in order to provide
>> higher performance with
a decreased quality of service. A
>> binding.jms element
configured in this way might not be
>> able to satisfy the
"atLeastOnce" policy intent. The SCA
>> runtime MUST raise an
error at deployment time if it is
>> unable to support the
combination of
>> @deliveryMode=NON_PERSISTENT
and the "atLeastOnce" intent
>> [BJM5000X]. More
generally, the SCA runtime must raise
>> an error if it is unable
to support the intents on a
>> binding in combination
with the specific configuration of
>> the JMS binding [BJM5000X].
>>
>> (I'm not entirely happy
with the above, because we would
>> then have two normative
statements, where one is just a
>> generalization of the
other, but I thought I'd get across
>> my notion for discussion
purposes.)
>>
>> Once again, my unfamiliarity
with policy spec strikes
>> again. Are both
of these normative statements actually
>> redundant with normative
requirements that come from the
>> policy specification?
If so, shouldn't we just reference
>> that part of the policy
spec?
>>
>> -Eric
>>
>> Simon Holdsworth wrote:
>>
>>
Folks, in
the interests of moving
>>
to a conclusion
on this here's my
>>
proposed
resolution. I think
>>
there is
also an issue with
>>
respect
to the lack of defaults
>>
defined
in the JMS binding for
>>
deliveryMode,
priority and
>>
timeToLive
attributes, I believe
>>
they should
be defined as having
>>
the same
defaults as on the JMS
>>
API (persistent,
4 and unlimited
>>
respectively)
so I will open a new
>>
issue for
that.
>>
>>
Proposal:
>>
>>
Keep the
deliveryMode attribute as
>>
is.
>>
>>
Replace
the final paragraph in
>>
section
5 (as updated in the
>>
resolution
to issue 48) to read:
>>
>>
This specification
does not define
>>
a fixed
relationship between the
>>
reliability
intents and the
>>
persistence
of JMS messages.
>>
Deployers/assemblers
can
>>
configure
NON_PERSISTENT for
>>
@deliveryMode
in order to provide
>>
higher performance
with a
>>
decreased
quality of service. A
>>
binding.jms
element configured in
>>
this way
might not be able to
>>
satisfy
the "atLeastOnce" policy
>>
intent.
The SCA runtime MUST raise
>>
an error
at deployment time if it
>>
is unable
to support the
>>
combination
of
>>
@deliveryMode=NON_PERSISTENT
and
>>
the "atLeastOnce"
intent [BJM5000X].
>>
>>
Regards,
Simon
>>
>>
Simon Holdsworth
>>
STSM, SCA
Bindings Architect;
>>
Master Inventor;
OASIS SCA
>>
Bindings
TC Chair
>>
MP 211,
IBM UK Labs, Hursley Park,
>>
Winchester
SO21 2JN, UK
>>
Tel +44-1962-815059
(Internal
>>
245059)
Fax +44-1962-816898
>>
Internet
-
>>
_Simon_Holdsworth@uk.ibm.com_
>>
<mailto:Simon_Holdsworth@uk.ibm.com>
>>
From:
ashok
malhotra
>>
_<ashok.malhotra@oracle.com>_
>>
<mailto:ashok.malhotra@oracle.com>
>>
To:
Eric
Johnson
>>
_<eric@tibco.com>_
>>
<mailto:eric@tibco.com>
>>
Cc:
David
Booz
>>
_<booz@us.ibm.com>_
>>
<mailto:booz@us.ibm.com>,
>>
_sca-bindings@lists.oasis-open.org_
>>
<mailto:sca-bindings@lists.oasis-open.org>
>>
>>
Date:
11/09/2009
22:12
>>
Subject:
Re:
[sca-bindings]
>>
Further
thoughts on issue BINDINGS-85
>>
>>
>>
------------------------------------------------------------------------
>>
>>
>>
>>
One of the
cornerstones of the
>>
intent model
is that intents can be
>>
satisfied
either intrinsically by
>>
a binding
>>
or by use
of config params on the
>>
binding.
I see Eric's message and
>>
some
>>
of the earlier
discussion saying that,
>>
no, intents
cannot be satisfied by
>>
config params.
If this is true, we
>>
need to
change the model.
>>
If this
is not the case, can we
>>
have a few
examples of how intents
>>
can
>>
be satisfied
by configuring a binding.
>>
>>
All the
best, Ashok
>>
>>
>>
Eric Johnson
wrote:
>>
> I also
like Simon's text, but
>>
for a different
reason.
>>
>
>>
> I just
checked with one of our
>>
JMS experts,
and he pointed out to me
>>
> that
PERSISTENT and
>>
NON_PERSISTENT
have little to do
>>
with the
policy
>>
> notions
of atMostOnce or
>>
atLeastOnce.
Instead, what
>>
matters
is the
>>
> particular
use of the JMS APIs.
>>
Are
transactions being used? What
>>
> kind
of acknowledgment mode is
>>
in play?
Does the particular JMS
>>
> vendor
provide any extensions
>>
that might
be used to satisfy the
>>
policies?
>>
>
>>
> So
I concur - policy settings
>>
shouldn't
map to a specific delivery
>>
> mode
setting, and the proposed
>>
text about
flagging a conflict
>>
between
>>
> delivery
mode and policy seems
>>
appropriate
to me.
>>
>
>>
> -Eric.
>>
>
>>
> David
Booz wrote:
>>
>>
>>
>>
Simon,
>>
>>
>>
>>
I don't like the idea of
>>
expanding
the meaning of any of the
>>
>>
reliability intents beyond
>>
their current
numerical meaning. It's
>>
>>
important (though not required)
>>
for intents
to have a consistent
>>
>>
meaning across bindings to
>>
enable binding
replace-ability
>>
within SCA
>>
>>
as much as possible. Therefore,
>>
given your
concern that
>>
>>
NON_PERSISTENT might encompass
>>
an implied
non-functional requirement
>>
>>
for a high speed transport,
>>
then I would
tend to favor the latest
>>
>>
solution that you just proposed.
>>
>>
>>
>>
Dave Booz
>>
>>
STSM, BPM and SCA Architecture
>>
>>
Co-Chair OASIS SCA-Policy TC
>>
and SCA-J
TC
>>
>>
"Distributed objects first,
>>
then world
hunger"
>>
>>
Poughkeepsie, NY (845)-435-6093
>>
or 8-295-6093
>>
>>
_e-mail:booz@us.ibm.com_
>>
<mailto:e-mail:booz@us.ibm.com>
>>
>>
>>
>>
Inactive hide details for Simon
>>
Holdsworth
---09/11/2009 06:05:18
>>
>>
AM---Ashok, Comments
>>
inline.Simon
Holdsworth
>>
---09/11/2009
06:05:18
>>
>>
AM---Ashok, Comments inline.
>>
>>
>>
>>
>>
>>
From:
>>
>>
Simon Holdsworth
>>
_<simon_holdsworth@uk.ibm.com>_
>>
<mailto:simon_holdsworth@uk.ibm.com>
>>
>>
>>
>>
To:
>>
>>
>>
_sca-bindings@lists.oasis-open.org_
>>
<mailto:sca-bindings@lists.oasis-open.org>
>>
>>
>>
>>
Date:
>>
>>
09/11/2009 06:05 AM
>>
>>
>>
>>
Subject:
>>
>>
Re: [sca-bindings] Further
>>
thoughts
on issue BINDINGS-85
>>
>>
>>
>>
>>
------------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Ashok,
>>
>>
>>
>>
Comments inline.
>>
>>
>>
>>
ashok malhotra
>>
_<ashok.malhotra@oracle.com>_
>>
<mailto:ashok.malhotra@oracle.com>
wrote
>>
on 10/09/2009
18:41:27:
>>
>>
>>
>>
> Simon:
>>
>>
> Let me analyze this from the
>>
other side
i.e. what the reliability
>>
>>
> intents map to in terms of
>>
the DIMS
binding config params.
>>
>>
> The Policy Framework defines
>>
4 reliability
intents. Here is what,
>>
>>
in my
>>
>>
> understanding, they map to in
>>
>>
> terms of DIMS delivery mode:
>>
>>
>
>>
>>
> - atLeastOne: Persistent
>>
(this is
more than what is
>>
requested
but
>>
>>
that
>>
>>
> may be OK)
>>
>>
> - atMostOnce: Non-Persistent
>>
>>
> - exactlyOnce
>>
(atLeastOnce+atMostOnce):
Persistent
>>
>>
> - ordered: No appropriate
>>
config param.
Supported by the
>>
runtime.
>>
>>
> So, two questions:
>>
>>
> - Simon, is this what you
>>
suggested?
>>
>>
>>
>>
Yes, that's what I was
>>
suggesting.
The problem with this
>>
>>
relationship is that it is
>>
asymmetric
- you can't say
>>
"atMostOnce
>>
>>
implies delivery mode is
>>
Non-Persistent"
because if
>>
exactlyOnce
is
>>
>>
required, it also requires
>>
atMostOnce,
and in that case
>>
delivery
mode
>>
>>
is Persistent.
>>
>>
>>
>>
The problem for me is that
>>
while exactlyOnce
satisfies the
>>
abstract
>>
>>
numerical requirement of
>>
atMostOnce,
the cost of providing the
>>
>>
additional restriction of
>>
atLeastOnce
doesn't satisfy the
>>
(in my
>>
>>
opinion expected)
>>
non-functional
requirement of
>>
atMostOnce
which is
>>
>>
provision of a high performance
>>
lightweight
message interaction. I
>>
>>
think that would be the reason
>>
the intent
would be selected by
>>
people
>>
>>
familiar with JMS, expecting to
>>
use it to
achieve a NON_PERSISTENT
>>
>>
deliveryMode for their messages
>>
sent by
the JMS binding.
>>
>>
>>
>>
Another way of saying this is
>>
that I don't
believe
>>
>>
deliveryMode=PERSISENT
>>
satisfies
the requirements of
>>
>>
deliveryMode=NON_PERSISTENT so
>>
I don't
believe we can say that the
>>
>>
JMS binding always satisfies
>>
atLeastOnce,
which I think Anish was
>>
>>
questioning.
>>
>>
>>
>>
My take on this issue is that
>>
if we can't
come up with a clear
>>
>>
relationship between the
>>
intents
and delivery modes that we
>>
can
>>
>>
explain in the JMS binding so
>>
that JMS-savvy
people know what to
>>
>>
expect from their JMS binding,
>>
or if we
retain the purely numerical
>>
>>
interpretation of the
>>
reliability
intents, then we
>>
should retain
the
>>
>>
current deliveryMode attribute
>>
and resolve
the issue by weakening
>>
the
>>
>>
current statement of
>>
incompatibility
along the lines:
>>
>>
>>
>>
Deployers/assemblers can
>>
configure
NON_PERSISTENT for
>>
@deliveryMode
>>
>>
in order to provide higher
>>
performance
with a decreased
>>
quality
of
>>
>>
service. A binding.jms element
>>
configured
in this way might not be
>>
>>
able to satisfy the
>>
"atLeastOnce"
policy intent. The
>>
SCA runtime
MUST
>>
>>
raise an error at deployment
>>
time if
it is unable to support the
>>
>>
combination of
>>
@deliveryMode=NON_PERSISTENT
and
>>
the "atLeastOnce"
>>
>>
intent [BJM5000X].
>>
>>
>>
>>
> - Others, does this make sense?
>>
>>
> All the best, Ashok
>>
>>
>
>>
>>
>
>>
>>
> Simon Holdsworth wrote:
>>
>>
> >
>>
>>
> > The JMS 1.1 specification
>>
has the
following to say about the
>>
>>
> > deliveryMode attribute
>>
(Section
4.7, Message Delivery Mode):
>>
>>
> >
>>
>>
> > A JMS provider must deliver
>>
a NON_PERSISTENT
message
>>
/at-most-once.
>>
>>
> > /This means that it may
>>
lose the
message, but it must not
>>
deliver
it
>>
>>
> > twice.
>>
>>
> > A JMS provider must deliver
>>
a PERSISTENT
message
>>
>>
/once-and-only-once/.
>>
>>
> > This means a JMS provider
>>
failure
must not cause it to be lost,
>>
>>
and it
>>
>>
> > must not deliver it twice.
>>
>>
> >
>>
>>
> > So it seems quite
>>
reasonable
to map the SCA
>>
atMostOnce
intent to JMS
>>
>>
> > delivery mode of
>>
NON_PERSISTENT,
and exactlyOnce to
>>
PERSISTENT,
>>
>>
> > although exactlyOnce is a
>>
profile
intent that combines
>>
atMostOnce
>>
>>
and
>>
>>
> > atLeastOnce, which would
>>
imply to
me that atLeastOnce maps
>>
to a JMS
>>
>>
> > delivery mode of
>>
PERSISTENT.
Although this does
>>
make life
quite
>>
>>
> > difficult, because bindings
>>
that require
exactlyOnce do also
>>
require
>>
>>
> > atLeastOnce.
>>
>>
> >
>>
>>
> > The only question I have
>>
left with
regards to removing the
>>
>>
> > deliveryMode attribute as
>>
the resolution
to this issue is
>>
whether
we
>>
>>
> > should mandate in the JMS
>>
binding
spec a specific mapping of
>>
these
>>
>>
> > intents to deliveryMode
>>
values,
or remain silent and leave
>>
that
>>
>>
> > interpretation up to the
>>
SCA runtime.
>>
>>
> >
>>
>>
> > If we were to mandate the
>>
mapping,
then the resolution to
>>
the issue
>>
>>
> > would be to remove the
>>
deliveryMode
attribute, and
>>
replace
the
>>
>>
> > following paragraph in
>>
section
5:
>>
>>
> >
>>
>>
> > Deployers/assemblers can
>>
configure
NON_PERSISTENT for
>>
>>
@JMSDeliveryMode
>>
>>
> > in order to provide higher
>>
performance
with a decreased
>>
quality
of
>>
>>
> > service. A binding.jms
>>
element
configured in this way
>>
cannot satisfy
>>
>>
> > the "atLeastOnce" policy
>>
intent.
The SCA runtime MUST raise
>>
an error
>>
>>
> > for this invalid
>>
combination
at deployment time.
>>
>>
> >
>>
>>
> > with:
>>
>>
> >
>>
>>
> > The JMS delivery mode used
>>
to send
messages from a JMS binding
>>
>>
> > instance which requires the
>>
atMostOnce
intent and not the
>>
>>
atLeastOnce
>>
>>
> > intent MUST be
>>
NON_PERSISTENT
[BJM5000X]
>>
>>
> > The JMS delivery mode used
>>
to send
messages from a JMS binding
>>
>>
> > instance which requires the
>>
atLeastOnce
intent MUST be PERSISTENT
>>
>>
> > [BJM5000Y]
>>
>>
> >
>>
>>
> > Given the deliveryMode
>>
default
is PERSISTENT, we could
>>
also say:
>>
>>
> >
>>
>>
> > The JMS delivery mode used
>>
to send
messages from a JMS binding
>>
>>
> > instance which does not
>>
require
either of these intents
>>
MUST be
>>
>>
> > PERSISTENT [BJM5000Z]
>>
>>
> >
>>
>>
> > In fact these could all be
>>
collapsed
into a single statement:
>>
>>
> >
>>
>>
> > The JMS delivery mode used
>>
to send
messages from a JMS binding
>>
>>
> > instance MUST be
>>
NON_PERSISTENT
if it requires the
>>
atMostOnce
intent
>>
>>
> > and not the atLeastOnce
>>
intent,
and PERSISTENT otherwise
>>
[BJM5000X]
>>
>>
> >
>>
>>
> > Comments?
>>
>>
> >
>>
>>
> > Regards, Simon
>>
>>
> >
>>
>>
> > Simon Holdsworth
>>
>>
> > STSM, SCA Bindings
>>
Architect;
Master Inventor; OASIS
>>
SCA Bindings
>>
>>
TC Chair
>>
>>
> > MP 211, IBM UK Labs,
>>
Hursley
Park, Winchester SO21 2JN, UK
>>
>>
> > Tel +44-1962-815059
>>
(Internal
245059) Fax +44-1962-816898
>>
>> > > Internet -
>>
_Simon_Holdsworth@uk.ibm.com_
>>
<mailto:Simon_Holdsworth@uk.ibm.com>
>>
>>
> >
>>
>>
> >
>>
>>
> >
>>
>>
>>
------------------------------------------------------------------------
>>
>>
> >
>>
>>
> > /
>>
>>
> > /
>>
>>
> >
>>
>>
> > /Unless stated otherwise above:
>>
>>
> > IBM United Kingdom Limited
>>
- Registered
in England and Wales with
>>
>>
> > number 741598.
>>
>>
> > Registered office: PO Box
>>
41, North
Harbour, Portsmouth,
>>
>>
Hampshire PO6
>>
>>
> > 3AU/
>>
>>
> >
>>
>>
> >
>>
>>
> >
>>
>>
> >
>>
>>
> >
>>
>>
> >
>>
>>
>>
>>
>>
>>
>>
>>
>>
------------------------------------------------------------------------
>>
>>
/
>>
>>
/
>>
>>
>>
>>
/Unless stated otherwise above:
>>
>>
IBM United Kingdom Limited -
>>
Registered
in England and Wales with
>>
>>
number 741598.
>>
>>
Registered office: PO Box 41,
>>
North Harbour,
Portsmouth, Hampshire
>>
>>
PO6 3AU/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
------------------------------------------------------------------------
>>
>>
/
>>
>>
/
>>
>>
>>
>>
/Unless stated otherwise above:
>>
>>
IBM United Kingdom Limited -
>>
Registered
in England and Wales with
>>
>>
number 741598.
>>
>>
Registered office: PO Box 41,
>>
North Harbour,
Portsmouth, Hampshire
>>
>>
PO6 3AU/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
---------------------------------------------------------------------
>>
To unsubscribe
from this mail
>>
list, you
must leave the OASIS TC that
>>
generates
this mail. Follow this
>>
link to
all your TCs in OASIS at:_
>>
__https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>>
>>
>>
>>
>>
>>
>>
------------------------------------------------------------------------
>>
>>
/Unless
stated otherwise above:
>>
IBM United
Kingdom Limited -
>>
Registered
in England and Wales
>>
with number
741598.
>>
Registered
office: PO Box 41,
>>
North Harbour,
Portsmouth,
>>
Hampshire
PO6 3AU/
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from
this mail list, you must leave the
>> OASIS TC that generates
this mail. Follow this link to all
>> your TCs in OASIS at:
>> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
>>
>>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]