Hi! Jame,
On Mon, 13 May 13, you wrote to me:
PQ>> -echomailjam I:\FLAG_DIR\sendmail.sem
PQ>> Such a facility for the other bases would be nice(?). 8-).
(NB. I am actually mis-using the facility.)
RC> Indeed it would... I see in the code where it's done for JAM
RC> messagebases; perhaps could just duplicate that for the other message
RC> base types, using the 'standard' flag files for them. I've made a
RC> note about it but I've no idea when I might be able to look at it any
RC> closer myself...
Taking the advice from Mark's note, it may be possible to specify a generic
base filename instead. E.g. either 'echomail' or 'netmail, and the extension
stipulates the messagebase type: .jam, .sq, .msg, for the types that the SMAPI
version supports. Something like:
-echomail [path]\echomail
-netomail [path]\netmail
That way a system can also use the files for their originally-intended
purpose: a record of the messagebase files and the message numbers
newly-written. Any external scheduler/processor can then determine the
particular action to be conducted on the new mails, depending on the base type.
RC> (I'm focusing for now on the Debian packaging for
RC> JamNNTPd ...)
Sweet.
RC> I'd already started a GIT repo for the smapi version, which I'm
RC> calling SmapiNNTPd at least for now, but I haven't done much more
RC> than that. I want to get an updated smapi library package first, plus
RC> I'm not sure where to make it public. May ask the Husky developers
RC> about it; (been wanting to discuss GIT repos for the husky apps in
RC> any case). Will likely at least mirror it to GitHub.
Understood. My best wishes follow you through that tumult. :)
Cheers,
Paul.
... I only started a BBS to save on the phone bill.
--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
|
