Closed Bug 390474 Opened 14 years ago Closed 14 years ago

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

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9alpha8

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file)

Attached patch Proposed fixSplinter Review
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.
Attachment #274790 - Flags: superreview?(brendan)
Attachment #274790 - Flags: review?(benjamin)
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
> 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.
Attachment #274790 - Flags: review?(benjamin) → review+
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
Attachment #274790 - Flags: superreview?(brendan) → superreview+
Summary: [FIX]Make nsBinary*Stream::ReadObject/WriteObject work → [FIXr]Make nsBinary*Stream::ReadObject/WriteObject work
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.
Attachment #274790 - Flags: approval1.9?
Attachment #274790 - Flags: approval1.9? → approval1.9+
Checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.