Closed Bug 588335 Opened 11 years ago Closed 11 years ago

Investigate adding consumer-identifier to startupcache

Categories

(Core :: XPCOM, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: benedict, Assigned: benedict)

References

Details

Attachments

(1 file)

Eg, IDs added by mozJSComponentLoader have js:/chrome:// ids, instead of just chrome://.
Assignee: nobody → bhsieh
Depends on: 520309
bsmedberg / bz / brendan, do you think this is worth it? I suggested it during review on the possibility that different consumers might try to serialize data keyed on the same URI. But maybe that's an unimportant concern. Not sure what precedent fastload had here.
fastload wrote data from different consumers into different files, so there would be no possibility of collision between them. In startupcache, collision is possible (though it seems unlikely that current clients will write the same URI as each other).
Yes, I figured that's how it worked already! There should not be bare URIs as key names, they should always have a prefix identifying who stored them/expects to consume them.

I recommend something other than js: such as jsloader:file://.. or xulprototype:chrome://...
Should block, then.
blocking2.0: --- → ?
blocking2.0: ? → final+
Probably the easiest implementation is just to change put/get buffer APIs to accept a second in-parameter, which is the prefix.
Why can't you just prefix the string?
Yeah, I guess it's okay to just have that as a convention.
Attachment #479580 - Flags: review?(dwitte)
Comment on attachment 479580 [details] [diff] [review]
adds prefix to mozJSComponentLoader consumer

r=dwitte
Attachment #479580 - Flags: review?(dwitte) → review+
http://hg.mozilla.org/mozilla-central/rev/4fae29935080
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.