[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] feedback on WSRP 0.8
Thanks for the comments ... comments intertwined with <rt> </rt>
Alejandro
Abdelnur To: wsrp-wsia@lists.oasis-open.org
<alejandro.abdeln cc:
ur@sun.com> Subject: [wsrp-wsia] feedback on WSRP 0.8
10/31/2002 09:25
PM
Following some random feedback on the spec.
Alejandro
General Comments
-----------------------------------------------------------------------
The spec dives into defining many of the structures without any
functional explanation of their use, kind of a Javadoc. It would help if
we start with the functional description of a operation and then we go
in detail about the data structures the operation uses.
Undefined concepts are used to define new concepts.
<rt>
People had found it difficult to discuss the operations without the data
structures being known. It also didn't work to intertwine the introduction
of data structures with the operation's description. The best we have so
far is this reference like data structure definition followed by
operational descriptions.
</rt>
-----------------------------------------------------------------------
Specific Comments (P##/L##: Page/Lines)
-----------------------------------------------------------------------
*P7/L31-34
Here we are introducing the concrete term 'portlet'.
Why not use it through out the spec instead the more abstract 'entity'?
<rt>
Note that the section you point to relates to specific motivating
scenarios. The intro also discusses that the specification applies more
generally than this scenario. Picking a term that communicates to
developers that the spec is portal/portlet specific would appear to me to
be a mistake.
</rt>
-----------------------------------------------------------------------
*P8/L1-6
I not think this reflects what the protocol does today.
<rt>
Good catch ... "data-oriented" deleted
</rt>
-----------------------------------------------------------------------
*P8/L14
At first, the e.g gives the idea to indicate that the portlets are
producers. I had to read that sentence a couple of times to realize that
was not the case.
<rt>
If others also find this confusing, I could use a suggested rewording ...
</rt>
-----------------------------------------------------------------------
*P23/L25-31
This section should mention the HTTP/SOAP transport. It's talking about
Cookies.
<rt>
parens modified to:
"(e.g. J2EE load balancing depends on the JSessionID cookie and HTTP
transport)"
</rt
-----------------------------------------------------------------------
*P23/L40
"New Data Structures" Why new, they are the first ones being defined.
I would remove "New" from all the data structure titles, they are
already subsections.
<rt> agreed ... done </rt>
-----------------------------------------------------------------------
*P24/L15
Shouldn't we define Properties (as we define Extensions) before using them.
<rt>
I've struggled with this a bit. The question is whether ALL structures
should be defined before they are referenced. Currently most definitions in
the interface sections occur because an operation references the data
structure. We could move all up in this style and then just have section 11
be a set of cross references (or deleted since that exists in the TOC).
</rt>
-----------------------------------------------------------------------
*P24/L15
How dynamic this information is supposed to be. If the consumer caches
it, how does it know when it should re-fetch?
<rt>
The question that keeps arising is how much of a back-door eventing model
do we want to include. I'm not comfortable with hacks here and there
outside of a full event model (which we deferred to v2).
</rt>
-----------------------------------------------------------------------
*P24/L33-34
It's confusing to what cookies this refers to. I know (I think) it's
refers to consumer-producer cookies but this it seems to indicate
client-consumer.
<rt>
Sentence changed to "A Consumer interacting with a Producer that has set
requiresCookieSupport to ‘true’ MUST act as a network intermediary for its
End-Users, in particular properly managing cookies the Producer sets." ...
is this clearer?
</rt
-----------------------------------------------------------------------
*P25/L14-20
profileKey is effectively the equivalent of a principal (for the
consumer-producer interaction). Why not call it principalID?
<rt>
As people have probably noticed, my key concern with the name of fields is
that they carry enough semantics to be meaningful while not misleading some
portion of the developer community. Can you point to places where the
equivalent is called a pricipalID? Would others find this a clearer name?
</rt>
-----------------------------------------------------------------------
*P27/L6
refHandle is being defined using a entityHandle that has not being yet
defined.
<rt>
entityHandle was first introduced in section 1.2.1
</rt>
-----------------------------------------------------------------------
*P27/L35
Structure for caching is being defined but there is not explanation on
how cache it suppose to work.
<rt>
This is the pattern of describing structures before the operational
descriptions ... in this case the later is in section 5.2.1
</rt>
-----------------------------------------------------------------------
*P29/L24
either/or is exclusive, isn't it? If so it should be just or.
<rt>
Field has been deleted.
</rt>
-----------------------------------------------------------------------
*P29/L39
'response:' it should read 'refhandleContext'
<rt>
Thanks
</rt>
-----------------------------------------------------------------------
*P35/L1 (picture)
What is the intended behavior when a fault happens? Just an error?
If so why not just throw a fault instead have a parameter with the value
Fault?
<rt>
The proposal has a value of 'Fault' as the means by which a Consumer forces
the configuration record to be read-only. This field is all about the
Consumer expressing what the Producer may do if the entity requests a
change in its persistent state.
</rt>
-----------------------------------------------------------------------
----------------------------------------------------------------
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] | [Elist Home]
Powered by eList eXpress LLC