wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Target for submission of WSRP to OASIS
- From: Michael Freedman <Michael.Freedman@oracle.com>
- To: WSRP <wsrp@lists.oasis-open.org>
- Date: Thu, 26 Jun 2003 14:28:57 -0700
Title:
Not sure if I can make this call tomorrow so will send out some questions/comments
ahead, just in case.
Also, Rich can you send out a more detailed description of the schedule using
both the current dates and the potential new dates [with the one month slip]?
I.e. rather then just focus on 7/11 vs. 8/11 it is instructive to see where
the end dates are.
My position:
I think there are two independent questions to consider:
a) Have we gained enough experience with WSRP [both implementation and interoperability]
since approving the Technical Committee specification to satisfy ourselves
that what we have is solid and ready for approval?
b) If the answer to (a) is yes, then should we in addition tie the approval
of WSRP to JSR 168's schedule to make sure they exit the change making period
as a unit?
My answer to (a) is yes we are ready. A reasonable amount of successful
interoperability testing has occurred in the past 6 weeks. Moreover, there
doesn't appear to be a mass backlog of new interoperability testing coming
online in July. I think we have achieved a good objective measurement that
being demonstrating real interoperability between different vendors using
3 different platforms [for both producers and consumers]: .NET, AXIS, SUN-RI.
My answer to (b) is no we should not tie ourselves to JSR 168's schedule.
Though in practice I think most folks would agree with this [particularly
going forward] the obvious question is what's the harm in doing so now? Its
only a month delay. The practicality is we don't know its only a month delay.
Its only a month delay if JSR 168 doesn't change [and hence we wasted the
month] Though Public review would be schedule to end in mid-August, changes
that occur during this review cycle, [particularly those entirely unrelated
to wsrp] could cause a further review cycle. Furthermore, unlike the OASIS
process, the JSR spec leads/companies have absolute control over the schedule.
We would be tying our schedule not to an open process but one where 2 companies
control the schedule in an environment where these companies have showed
a willingness to manipulate these schedules for other then technical specification
reasons. I.e. the risk of waiting a month/tieing ourselves to the JSR schedule
is [at a minimum] we lose a month and at a maximum we lose a couple of months.
For me this is a "high" risk given we are 6-9 months late in delivering
our specification. To take this risk I would want to have a reasonable expectation
of reward. I.e. What is the likelihood we will need to modify WSRP because
a problem is found via JSR 168 by early August? I don't see how the answer
to this is any greater/higher then the similar question I asked myself to
answer (a) above -- i.e. What is the likelihood that waiting another month
will allow WSRP implementors/interop testers to uncover problems we need
to fix? Therefore I would assert if we are comfortable going forward based
on (a) we should not delay based on (b) as our expectations for uncovering
problems is no higher.
So, why do I think JSR 168 Public review will not likely impact WSRP? From
a mere read and comment on the specification perspective, portlet function
has been debated/resolved now by two independent though cooperating groups
and we seem to have reached a mutual common model. It is no more conceivable
to me that a 3rd party to this process will enter at the 12th hour and cause
us to tilt the JSR 168 cart then for the same to occur with WSRP. As we
have been in "public review" of WSRP for the past 6 weeks with neary a wispher
from 3rd parties I have similar confidence for JSR 168.
In addition to a mere specification read, JSR 168 Public review affords vendors
an opportunity to acutally distribute pre-release software in support of
the JSR. It is therefore possible, that vendors will provide such software
on top of WSRP and through the course of actual public use will uncover issues
that need addressing. Though this sounds like an attractive reason to tie
ourselves to JSR 168's schedule the details indicate otherwise. The basic
argument in support of this is we should delay finalizing WSRP until we have
reasonable [real world] experience with its use by independent parties. Because
of the complexity of WSRP, something like JSR 168 [on top of WSRP] is needed
to bring portlet development to the masses - and its only once we get this
level of experience can we safely say we are done. The problem here is that
if you believe in this sentiment a one month delay is too short. Even if
available, folks don't acquire, adopt and develop reasonably complex solutions
within a month of a specification being made public. At best we should expect
to install and run the samples and make basic modifications. This is both
due to the practicalities of dealing with new [alpha] software and the mere
fact that the standards aren't fixed/haven't been approved. For me, such
"kicking the tires" doesn't add significant value to our process of stablizing
and standardizing WSRP.
-Mike-
Rich Thompson wrote:
Late discussion on today's TC call related
to when WSRP should be submitted to OASIS. Issues raised:
- JSR 168 public review plans were delayed
from our discussion in May.
- JSR 168 is just now going into public
review (expected public visibility on 7/11 [Sun is closed next week])
- There has been a strong intent of producing
aligned WSRP and JSR 168 standards in order to keep the programming models
straight forward
- Risk raised is that submitting now
would leave reviewing how the alignment changes during the JSR 168 public
review with the OASIS Board. Any comments they produce would likely start
a new 3-month cycle.
- Discussion in May set a target of submitting
in July as:
- Several vendor products are interoperating.
The number involved continues to grow (currently at 5).
- Errata emanating from these tests
has tended toward clarification rather than changing things that are broken.
- Any real issues are more likely
to occur once the spec is released and supported by a number of vendors and
will have to be fixed in v1.1 or v2.
Question raised:
Why not delay 1 month to provide greater
opportunity to test interoperability and vet any impacts of issues discovered
during the JSR 168 public review?
Please use this email thread to vet opinions
on this subject. In addition, I will schedule an 8 PT, 11ET, 5CET teleconference
for tomorrow (6/27) for those wishing to discuss it verbally. I will also
establish a vote in the Kavi system for this question with a closing date
of next Tuesday (7/1).
Rich Thompson
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]