An RDF file that is referenced using a resource: URL isn't persistent, since the Flush() call fails. Need to mangle the resource: URL into a file URL.

Setting M5 target milestone.

Hyatt: I think this bug is invalid. What we really want is for netlib to provide an output stream on *any* URL that can be written to. Let's talk to gagan et. al. about this.

I agree that we want it to work that way eventually. However, it's unlikely we're going to see this until the new NetLib lands (which won't be for a while). I need this to work now. It's a 2 line change to export the current mangleResourceIntoFileURL function. For now, we can just call that function (with the knowledge that we don't want it to work that way). When the new NetLib lands with our fix, then we can do the right thing. After we have it working with the mangle function, I can refile this bug against gagan or judson and they can go off and do the right thing in the next NetLib. Sound cool to everyone, or is the right fix something you want to make to the current NetLib?

targetting M5 per hyatt's earlier comment. Please keep a reminder bug open so you don't forget to undo the kludgy fix.

There is a decent workaround for my particular problem, so I'll be using it. I'm going to reassign this to gagan, so he knows about it for NetLib: The NextGeneration. :)

Deffered till Necko lands...

Deferring till Necko lands...

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Once the tree stabilizes enough with Necko, we will push the mangling functionality from your area to the resource: protocol hack. So am pushing this till then. And dropping the severity. Marking component as Necko.

This bug now has higher priority since this must now work in order to edit the chrome registry. Maybe waterson should take it and hack something up on the RDF side.

Is this bug still valid?

i'll hack around it. chrome urls are never going to map to resource urls because of this though.

Is this the same thing that Hyatt reported last night: how can i (without loading the url) take a resource url and obtain the file url it maps to? I suggested that he could call nsIIOService::NewChannel on the resource URL, get the channel, call GetURI, call GetSpec returning the file: URL, and then release the channel. He said this was an acceptable solution.

basically a RDF data source can't be flushed to disk unless it knows the file url.... i have to reference it via a file url or have a way of going from resource to file.

So from your message earlier it sounded like my proposed solution would be ok, and we didn't need a specific API for resolving a resource: URL. I can still add one if you want, but it doesn't sound like I have to. Reopen this if you change your mind.

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

VERIFIED: resource url's map to file URL's in today's world.