After looking through the current issues
document, I think I would like to see one added - Is it useful to have a
Consumer flag provided during a pbia() or handleEvents() call which specifies
that it will not send any events?
Thanks.
Scott
From: Rich
Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, September 16, 2004
5:34 AM
To: wsrp-coord@lists.oasis-open.org
Subject: RE: [wsrp-coord] Comments
on Events Semantics Doc
It is good to work through how we got to the current state ...
3. The
publishedEvents are expected to be defined by the portlet in some manner,
though this could be via an include of someone else's definitions. I believe
the thought behind handledEvents being different was a greater likelihood that
these would be from another namespace. It would be more reliable if they were
of type EventDescription as well.
4. A
portlet handling a SetCustomerID event could easily be expected to generate
other events related to the side effects of doing that update. In general,
handling an event should be expected to generate the same events that
processing the equivalent from a user's interaction with the portlet's markup,
with the exception of generating the event which is being processed.
5. The
use case for Consumers that only handle simple payloads is Consumers who have
already have an event distribution engine and that engine only handles simple
payloads.
Do you
think we need to open additional issues related to any of these areas or just
discuss them within the current set?
Rich
"Goldstein, Scott"
<Scott.Goldstein@vignette.com>
09/15/2004
08:35 PM
|
To
|
Rich Thompson/Watson/IBM@IBMUS,
<wsrp-coord@lists.oasis-open.org>
|
cc
|
|
Subject
|
RE: [wsrp-coord] Comments on Events Semantics Doc
|
|
Thanks for the comments, Rich.
1.
Sounds
good.
2.
Sorry.
My misunderstanding.
3.
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[]?
4.
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?
5.
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