I’ve got several questions regarding 3rd party app development for domino server with the C API; any and all help would be greatly appriciated…
Is there a platform independant way (api functions/variables) to determine which server task is loading an extension manager module (.so file) when MainEntryPoint() is called?. My code is only relevant to the smtp task, so it seems like a vaste of cpu cycles to run thru the initialization for all the other tasks.
Is there any cleanup functions needed on unix platforms for extension, similar to DLL_PROCESS_DETACH on Windows?
How can I insert arbitrary SMTP header fields into an open email (i.e. X-Content-Filter-Score: 5.0 (or similar))? (This has been asked before on the list but received no reply)
When using either NSFNoteDetachFile() or NSFItemDelete() to remove certain attachments from emails, the attachment only gets truncated. What do I have to do to remove the attachment icon from the email as well?
Regarding #4, I did this more or less successfully in R5. It is not a very straight-forward process - you have to parse through the CD records that comprise the message looking for the ones that mark the beginning and end of the attachment graphic in the body of the message.
I hate to be one of those “helpful” people who respond “search the forum”, but all the info I obtained on this I found in the forums. It was just a matter of knowing what to look for. Hope this at least points you in the right direction.
#1) No OS independent way, and even on UNIX machines it varies. They all basically use getpid, and then use the processid with readlink on Linux or ioctl(fd, PIOCPSINFO, …) on Solaris or getprocs on AIX, etc. On Windows, you would use GetModuleFilename(GetModuleHandle, …), for what it is worth.
#2) You shouldn’t need to, if I understand what you mean.
#3) If it is an extension manager call, just add the field. I guess I am not sure what you are asking. Create a buffer with the appropriate content, then append the field with the appropriate type.
#4) The icon is part of a file hotspot. You have to process the CD records to get rid of it, not just remove the item it points to.
#3) If it is an extension manager call, just add the field. I guess I am not sure what you are asking. Create a buffer with the appropriate content, then append the field with the appropriate type.
–
What I was wondering about for #3 was basically which ITEM_CODE to use in MailAddHeaderItem(). Just after posting I stumbled accross MAIL_CORRELATION_ITEM_NUM which I guess is what I was looking for. Sorry to post a RTFM question; don’t know how I missed this bit… too much (or not enough) coffee I guess.
Simply keep a counter so that your extension manager gets initialized only once. Every loading server addin causes your extension mgr code to be called, so just init once and then exit right away for all other calls. If you really only want to init if in fact the SMTP addin gets loaded, AFAIK there is no public SDK call to find the loading module’s process name…
Well, if I understand correctly how shared libraries work on linux, each process gets a private copy of the shared library’s data segment, so any such counter would be initialized upon loading the .so file for that process, in effect re-initializing the ext mngr for every server process. I’ve heard of linkers that allow ‘global’ instances in shared objects as oppesed to ‘per-context’ but I don’t know if GNU ld can do that (anyone?). The extmngr sample code uses a global variable like that, but that code is intended for Windows (so I assume it works there), but it doesn’t do any good under linux.
So, the current situation is that EMRegister() is being called for every server process for a couple of EM_SMTP* events when (obviously) it’s only relevant for the smtp process. Is this considered normal/acceptable or should I take additional steps to prevent this?
“Is this considered normal/acceptable or should I take additional steps to prevent this?”
AFAIK this is how it always has been. Another easy and efficient way to deal with it is to use an MQueue.
Upon first load/initialization of your extmgr, check for your own MQueue. If it doesn’t exist, you know you have never been loaded before, so init and create the MQueue. For the next instance, the MQueue will exist, so you know you’ve been loaded already.
MQueues are very efficient and fast, and are just global memory anyway (Domino managed, therefor portable)
