Revisiting the War on RDF, especially folder lookup

Kent James 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 
nsMessenger.cpp

:rkent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20130123/fb42c416/attachment.html>


More information about the tb-planning mailing list