Thanks for the comments, Rich.
- Sounds
good.
- Sorry.
My misunderstanding.
- I’m
not sure I’m following what you mean by, “if we make it an
EventDescription[], it would mean that the schemas defining such
interesting events would need to be reachable so that they could be dealt
with via an include”. Could you elaborate? Also, how is having
this field be of type, EventDescription[], different from having the publishedEvents
field of type EventDescription[]?
- I
understand the advantage of flexibility. However, it’s not
clear to me when it would be used. This is why I was curious if
anyone had any specific use cases. The concern I have with it is
that it opens up the possibility of performance problems and even infinite
recursion. Therefore, you would want to implement a Consumer to
limit the number of chained events it would handle before calling
getMarkup(). On the nth event, then, you could call the
handleEvents() operation with a flag stating that the Consumer will no
longer send events. A portlet may then be able to react to this,
thereby putting itself in a proper state in order to serve the subsequent getMarkup()
call. Though an infinite loop is unlikely, it’s definitely
possible, especially in the case where the Consumer allows event mapping
within a configuration screen and the administrator maps the events in a
feedback fashion. Anyone else have thoughts on this?
- Why
would it be beneficial for a Consumer to only handle events that were
simple? I don’t see it as being easier to implement, since the
Consumer can pass data of type any from one message to the next without actually
reading it. Was there another purpose behind it?
Thanks.
Scott
From: Rich
Thompson [mailto:richt2@us.ibm.com]
Sent: Tuesday, September 14, 2004
2:14 PM
To:
wsrp-coord@lists.oasis-open.org
Subject: Re: [wsrp-coord] Comments
on Events Semantics Doc
My take:
1.
I would like to turn the open questions into an issues list that we
systematically work our way through. I think this will need people to step up
to fleshing out the pros and cons of the various issues so that a decision can
be reached. This will likely be a list that grows a bit as people now see the
changes we have discussed in the broader context of the spec.
2.
The discussion about '/' or '.' was left open the last time it was discussed.
3.
I think the reason we had set the handled events as QName[] was that portlets
could easily be handled events defined in other namespaces. I see the issue you
raise ... if we make it an EventDescription[], it would mean that the schemas
defining such interesting events would need to be reachable so that they could
be dealt with via an include.
4.
The semantics are that an interaction is an event that has been serialized to
markup. I can't remember an eventing system where single generations of events
ever dominated, though the number of generations is often small.
5.
This question deals with how a Consumer advertises its capabilities. The axis
discussed included doing event distribution, only distributing events whose
payloads are of type string and full support for distributing generated events.
Rich
"Goldstein, Scott"
<Scott.Goldstein@vignette.com>
09/14/2004 02:55 PM
|
To
|
<wsrp-coord@lists.oasis-open.org>
|
cc
|
|
Subject
|
[wsrp-coord] Comments on Events Semantics Doc
|
|
Rich mentioned in the last conference call that now was a good time to
bring up questions/issues with the current eventing semantics doc, given that
it’s being put into the 2.0 spec. Here are our comments:
1.
There are still a significant number
of open questions listed in the doc which appear not to have made it into the
WSRP 2.0 spec draft. Will we continue working with the semantics doc and
then push the changes into the WSRP 2.0 spec? Or, does it make sense to
add the open questions to the WSRP 2.0? It doesn’t seem to make
sense at this point to apply changes to both docs.
2.
Minor - In the suggested hierarchy
of event names, we had discussed changing the “/”’s to
“.”’s. I see that the open question about confusion
with Xpath is still there. I don’t recall, however, anyone having a
problem changing to “.”’s. Any thoughts on this?
3.
In the PortletDescription, why is
the type of the handleEvents element a QName[] instead of a an
EventDescription[]? Imagine the following scenario: I consume a
portlet which states that it can receive events of name,
“ns1:zipCodeEvent”. Imagine that I consume another portlet
which states that it published an event with name,
“n55:myZipCodeEvent”, data type, “xsd:string”, and
description, “The current zip code selected.” As a portal
administrator, I may want to map the published,
“n55:myZipCodeEvent” to be received by the first portlet as,
“ns1:zipCodeEvent”. Unfortunately, without a data type and description,
I don’t know what the first portlet is expected. However, if
handleEvents was an EventDescription[], all of this information would be
provided, facilitating this mapping.
4.
Can someone provide a specific use
case around event chaining (returning events from a handleEvents() calls)?
I’m having trouble seeing the need for this. The only
possibility that I can some up with, is for sending an ACK, which might be
useful based on the way we’re defining the Consumer as an intelligent
entity capable of making the decision not to send events. Is this the
case that has come up or are there others? Also, would the sending of
ACKs be our best practice suggestion of verifying event propagation?
5.
Open Question #3 – What is the
difference between a simpleEvent and a complexEvent?
Thanks.
Scott
|