The case I was attempting to make is that
the modify registration fault is an "extension" of a registration
fault that can be recovered from. I understand that one can view
InvalidRegistrationFault more as commandment to never again use the
registration handle rather than a signal that a registration is, say, temporarily
unavailable (cf InvalidHandle?). In this view both ModifyRegistration and
InvalidRegistrationFault could extend a base RegistationFault.
From: Rich Thompson
Sent: 13 December 2004 14:10
Subject: Re: [wsrp]
I do not think the ModifyRegistrationRequired fault
should extend InvalidRegistration fault as their semantics are quire different
(repair this registration vs destroy this registration's artifacts). As to an
expanded description ... sounds like a good idea, I kept the initial pass
concise as this is in keeping with the other definitions in the table, but am
open to expansion of this or other fault descriptions. We should be careful
about what is prescribed behavior, though, as not all Consumers will be portals
with administrators ...
12/10/2004 04:55 AM
[wsrp] modifyRegistrationRequired fault
The draft spec does not seem to give much guidance on how to handle the
new proposed fault? I would expect
consumer processing for an end-user to abort
fault (affected portlets are not
rendered) and an admin to be notified to go and attempt a
modifyRegistration operation interaction with the faulting producer (correct me
if I'm wrong but Portal users may not even
the new modified registration until they log in
again). This leads me to two questions:
example usage of the new fault be better described?
the fault type be declared to extend the 1.0 InvalidRegistrationFault
common base type be inserted)?