Comment 22 for bug 320618

(In reply to comment #17)
> Note that nsISupportsPRBool may be deprecated (i.e doesn't work with libxul?),
> please check with #developers before following my advice :-)

I asked in #developers, and Callek said he "thought he heard something about them going away shortly after FF4", but no one had any further info on it being deprecated, and I wasn't able to find anything anywhere else about this either. Someone suggested that jsval may replace the functionality of the support primitives, but I don't think that would work here. It seems to still be working OK for me with comm-central (and libxul is already landed there, right?)

(In reply to comment #16)

> Also, does it make sense to add the new observer in this function already? I
> had the feeling you're adding the observer outside of the call each time
> createMemoryCalendar is called.

There's a comment in onStreamComplete that says it's important to add the observer only after all the events are adopted so the views won't be notified too early.

> > // File not found: a new calendar. No problem.
> >+ this.createMemoryCalendar();
> >+ this.mMemoryCalendar.addObserver(this.mObserver);
> >+ this.mObserver.onLoad(this);
> > this.unlock();
> Lets hope this doesn't cause dataloss in certain situations. While it totally
> makes sense when the file is really empty, do you think there are situations
> where there is no content because of an error, that would trigger this code?
> I'm not sure.

You're absolutely right - this could cause dataloss with a file on a network share - if it was disconnected before a refresh, all the events would be cleared, and if it was reconnected before a subsequent write operation all the previous data would be gone.

I think we should leave this case alone, it makes sense that if we leave the old events in view when the calendar is temporarily non-readable, the unwritten event could stay also and possibly be written if the calendar becomes connected and writable again.