390474 - [FIXr]Make nsBinary*Stream::ReadObject/WriteObject work

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

It would be nice to be able to deserialize and serialize individual objects via nsISerializable without having to create a fastload files and so forth.  This would mean we don't get single objects created for multiple pointers to the same object, but in some cases that's OK.

I considered using the "rv |=" pattern here, but some callers will actually care about errors, more or less... At least to figure out what went wrong.

Comment 1

[Brendan Eich [:brendan]]

Comment on attachment 274790 [details] [diff] [review]
Proposed fix

Does something actually need these default impls?

Nit: can you use CallQueryInterface in nsBinaryInputStream::ReadObject to avoid ugly casting?

/be

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Does something actually need these default impls?

Anything that wants to serialize things without a fastload file.  I'm planning to make use of this for serializing principals to base64-encoded strings for session restore for 1.9.

For Mozilla 2, as discussed we should have something better.

> can you use CallQueryInterface

CallQI is a template on its out param type.  I'd need to have an nsIFoo* for the right nsIFoo to use it.  All I've got is the IID of nsIFoo.  So sadly, no.

Comment 3

[Brendan Eich [:brendan]]

Comment on attachment 274790 [details] [diff] [review]
Proposed fix

Sure, ok -- just making sure these are going to be used. I didn't write them, but I didn't mean to preclude them, way back when (FastLoad daze, 2001 IIRC).

/be

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 274790 [details] [diff] [review]
Proposed fix

This patch implements some back-end functionality we'll need to serialize principals for various consumers (feeds and session restore come to mind).  Risk is low, since no one should be using these methods right now.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Checked in.