[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] The modification problem gets worse...
In the interest of continued pursuit, I'm still curious what your thoughts are on overcoming the problem I described originally.
--
Steve
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, March 13, 2003 2:36 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] The modification problem gets worse...
Jeff,
I've apologized to Steve for my knee-jerk reaction already. Let me offer
you the same apology. I agree that you gain a measure of confidence
through the use of an existing standard, I'm not really arguing that point.
What I'm arguing is the appropriateness of the specification that you elect
to use and I submit that if it doesn't fit then you should start afresh. I
never imagined that after two weeks there would be no outstanding issues
with a new approach. As you point out, my example is not fully formed and
I have not claimed that it is. What I am claiming is that none of these
issues, Search, Modify, or others that you will undoubtedly discover, are
insurmountable. What I'm proposing is that we examine what we really want
from this specification. I regret that we have not been present in the
committee for the past six months to pit proposals side-by-side on the same
timeline but have to resort to an accelerated debate, outside of any real
process. I still think the exercise is useful though, and if you are game
then I'd like to continue to pursue it and leave any resolution to our
conversation on Monday.
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/13/2003 11:06 |
| | AM |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Gearard Woods/Irvine/IBM@IBMUS |
| cc: provision@lists.oasis-open.org |
| Subject: RE: [provision] The modification problem gets worse... |
| |
>------------------------------------------------------------------------------------------------------------------------------|
Gerry,
You are incorrect about how DSML Modifications work. They do support
deleting value from an attribute, as well as adding a value to an
attribute. Even if delete was not supported (which it is), I could still
show a similar example of two different RAs adding a value to the same
attribute. Again, it works in the current specification, and does not
work in your proposal.
What you are illustrating quite well is the benefit of basing a new
protocol on work done in another one. We don't have to scratch our heads
and wonder how the protocol should behave. We have RFCs, books, user
communities, and vendor support to turn to for questions. I made this
point early in the discussion that we can be confident that the current
spec will work because we based it on another spec that is known to
work. We start over from scratch and we lose that.
This also illustrates the importance of examining other protocols that
are similar to what you are proposing. I think that the problems that
have arising originally around searching and now around modifications
illustrate the need to look at like protocols for validation that the
approach is sound and that it is likely to be adopted by the industry.
Unfortunately I am at loss as to what protocols we could compare it to.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, March 13, 2003 1:24 PM
To: Steve Anderson
Cc: Jeff Bohren; provision@lists.oasis-open.org
Subject: RE: [provision] The modification problem gets worse...
Steve,
Thanks for all the help. All kidding aside, there is no ability to
delete
specific values in the current SPML, it uses DSML modifications which
only
allow for attributes to be deleted, added or replaced in total. My
scenario still holds because you will not get the "value not found" or
"value already exists" errors that you are relying on.
Gerry
|---------+---------------------------->
| | "Steve Anderson" |
| | <sanderson@openne|
| | twork.com> |
| | |
| | 03/13/2003 10:17 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS, "Jeff Bohren"
<jbohren@opennetwork.com> |
| cc: <provision@lists.oasis-open.org>
|
| Subject: RE: [provision] The modification problem gets
worse... |
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
I've been following this thread, and it think Gerry's example here
actually
illustrates Jeff's point. I'll take a stab at explaining ...
In Gerry's example, after initial creation, two different RA's want to
change Item B. The first, RA1, wants to replace both 'values' (3,4)
with
two new values (5,6). The second RA, RA2, only wants to replace value 4
with value 5. RA1 executes first, followed by RA2.
In Gerry's example, it appears that the modifications can only be done
by
supplying the whole set (3,5), so the resultant set is just that --
(3,5).
The problem is that value 6 has been inadvertently replaced with value
3.
In Jeff's approach, the RA2 can perform the following:
- Modify B: remove value 4
- result: Value not found -- interpreted by RA2 to be fine,
since
this is the desired result anyway
- Modify B: add value 5
- result: Value already exists -- interpreted by RA2 to be fine,
since
this is the desired result anyway
The final value set for B is (5,6). No corruption.
Hope this helps.
--
Steve
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, March 13, 2003 12:56 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] The modification problem gets worse...
Jeff,
Your argument here and in your previous message is predicated on the
assumption that the RAs in my scenario hold the state of the data while
in
yours they do not. In yours they simply request a modification that is
independent of the current state of the data. You argue that this is
not a
race condition problem and that your scenario will not suffer from it.
Let's go through it again using your implementation:
RA 1 Entry RA2
create
A: 1,2
B: 3,4
read
A:1,2
B:3,4
replace
B: 5,6
A:1,2
B:5,6
replace
B:3,5
A:1,2
B:3,5
This is how the current specification works and according to you this is
fine. I'm not sure that I see much of a difference in the end result.
Please explain.
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/13/2003 05:22 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: provision@lists.oasis-open.org
|
| cc:
|
| Subject: [provision] The modification problem gets worse...
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
In a previous posting I have shown how the current proposal by Gerry
Woods
will cause data corruption when doing modifications. I have shown this
using a very simple case. Gerry has suggested that this could be
overcome
by a modification mechanism that uses XPath in combination with ldap
like
modification semantics. Although this alternative has not been fully
fleshed out, it will not work either. Even theoretically it will fail.
Let
me explain why.
Suppose a record has data that looks like:
<A>
<B>
<C>foo1</C>
<C>foo2</C>
<C>foo3</C>
</B>
<B>
<C>foo4</C>
<C>foo5</C>
<C>foo6</C>
<B>
</A>
No suppose RA1 wants to change the first B component. It would have to
issues a modification request with an XPath that refers to B where B has
foo1, foo2, and foo3. Now suppose the modification changes the record so
that it looks like:
<A>
<B>
<C>foo1</C>
<C>bar8</C>
<C>foo3</C>
</B>
<B>
<C>foo4</C>
<C>foo5</C>
<C>foo6</C>
<B>
</A>
Now suppose at a later time RA2 wants to remove the first B component
from
A. It would have to issues a modification request with an XPath that
refers
to B where B has foo1, foo2, and foo3. This request would now fail.
There
is no automatic way for RA2 to reconcile the differences.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]