Re: Issue #170 proposal - referencing to missing data

 Noah,
 of course the fault would be generated when a processor actually
encounters a reference it cannot resolve. I don't want to mandate
that all data be deserialized even when unnecessary.
 Anyway, I'm very nervous about you tying the term weak reference
with an optionally handled argument. Weak references, as I
understand them (according to Java), are references to data that
can disappear and the reference can still be handled graciously.
Optionaly handled arguments, as in LISP's (if a b c) form,
require some implementation support but don't require weak
references, on the other hand weak references don't always (nor
usually IMO) mean optionally handled arguments.
 I think that we don't need to put weak references into our data
model as they can be handled by the application equally well and
the slight optimization of weak references being inside our data
model and encoding is outweighed by the disadvantage of the
additional complexity, while weak references are used only in
very few special applications.
 Actually, the same argument could be used on partially
transmitted arrays. 8-)
 BTW, I think the current encoding does not forbid lazy
deserialization, IMHO, which can be used for implementing
optionally handled parameters.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 4 Dec 2001 noah_mendelsohn@us.ibm.com wrote:

 > Whenever we mandate a fault, we must be very careful about ordering.  I
 > would be reluctant to do anything that forced processsing, particularly of
 > a large message, to proceed in any particular order.
 >
 > Consider the case where there are several problems with a message, some
 > related to encoding and some not.  If we mandate the generartion of an
 > encoding fault, then we might be forcing processors to do more decoding
 > than the application needed to discover other problems.   Furthermore,
 > there's a general issue of weak references.  What if you're doing RPC and
 > by looking at argument #1 you decide that you don't even need to mess with
 > argument #3.  Should we still mandate that you check for the fault in a
 > bad reference out of #3?
 >
 > I think not.  Therefore I prefer Henrik's suggestion:  offer a standard
 > fault that MAY be used, and indicate that failure to resolve a reference
 > indicates that there is no value available for the node in the graph (a
 > new state we haven't had before) and that processors MAY generate the
 > standard fault when this situation arises.
 >
 > ------------------------------------------------------------------------
 > Noah Mendelsohn                                    Voice: 1-617-693-4036
 > Lotus Development Corp.                            Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------------
 >
 >
 >

Received on Tuesday, 4 December 2001 11:11:08 UTC