Revisiting the War on RDF, especially folder lookup
kent at caspia.com
Wed Jan 23 20:51:26 UTC 2013
On 1/22/2013 5:50 PM, Joshua Cranmer wrote:
> Okay, I hate top-posting, but I think it works best in this context.
> I'm not sure if you were proposing this or not, but there is one API
> aspect that I want to avoid if at all possible. I do not want there to
> exist an interface where the methods are only usable at certain times.
> By this, I mean that if I were to get an nsIMsgFolder object somehow,
> then I should be able to call any method (say, addMessageToFolder)
> without having to first call a method (say, createStorageIfMissing).
> This is not true of our API at present: nsIMsgDBHdr definitely
> violates this when applying filters, and I think "proto-folder
> objects" can exist (particularly for IMAP). In particular, this
> implies that if I have a folder object, then it appears to have the
> necessary backing storage.
What you are arguing if you think about it is that the folder objects
needs to be created in the context where enough is known about them to
properly initialize them. I'm fine with that. The implications are that
folder objects will be created directly using "new" on an implementation
of nsIMsgFolder in only two places: in an implementation of
nsIMsgIncomingServer to create a root folder, and in AddSubfolder in an
implementation of nsIMsgFolder.
After that, we are only talking lookup. Though I would prefer to just do
the lookup using a hash table of weak pointers in an existing service
such as nsIMessenger.idl (which already has the parallel method
nsIMsgDBHdr msgHdrFromURI(in ACString aUri)) I have no real objection to
doing it as a js service instead. Then that lookup service needs methods
like getFolderFromURI, addFolderToMap, and deleteFolderFromMap, which
will be called from the folder methods that add and remove folders.
These are all sync functions, since this is just a lookup service. Let's
just keep this simple.
If we need to do more complex things, like create a tree of folders from
a URL, let's just add that to the server and not complicate the lookup
service or method with that.
I've already done this myself in a related context in ExQuilla, where
the hash was:
// cache of items in memory
nsInterfaceHashtable<nsStringHashKey, nsIWeakReference> mItems;
It's a pain if you have never done it before, but it would not be
difficult for someone with experience to add this lookup service to
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning