G'day all - the other night I was thinking about what I can do to help extend ripMIME a bit - now, bascially this is
going to /break/ the mould a little - but perhaps it can be of some use.
There are several formats out there which need to be further decoded to bring things down to a lowest attachment state,
ie, zip files, tar, etc. While I'm not explicitly trying to turn ripMIME into an de-archiver, it certainly probably
will be one of its biggest uses.
The idea is - each file type required will be handled by a 'plugin' (Wonder if we'll be in violation of Eolas's plug-in
patent! ;-). The plugin will register a filetype signature/ID with ripMIME dynamically - ripMIME will then check
against those registered strings each time it encounters an attachment which it, itself cannot decode, the process will
then occur iteratively over any new attachments discovered.
What's everyone think?
I wish to leave it as a plug-in model, so that people who do not want to the extra baggage don't have to include it.
Also, I'd love it if there was a way to make it so that plugins would work without breaking each new version of ripMIME
- no doubt that's something which really is more dependent on good forward planning and requirements-discovery _before_
implementing.
Regards
--
Paul L Daniels http://www.pldaniels.com
Linux/Unix systems Internet Development
ICQ#103642862,AOL:pldsoftware,IRC:inflex irc.freenode.net
A.B.N. 19 500 721 806
going to /break/ the mould a little - but perhaps it can be of some use.
There are several formats out there which need to be further decoded to bring things down to a lowest attachment state,
ie, zip files, tar, etc. While I'm not explicitly trying to turn ripMIME into an de-archiver, it certainly probably
will be one of its biggest uses.
The idea is - each file type required will be handled by a 'plugin' (Wonder if we'll be in violation of Eolas's plug-in
patent! ;-). The plugin will register a filetype signature/ID with ripMIME dynamically - ripMIME will then check
against those registered strings each time it encounters an attachment which it, itself cannot decode, the process will
then occur iteratively over any new attachments discovered.
What's everyone think?
I wish to leave it as a plug-in model, so that people who do not want to the extra baggage don't have to include it.
Also, I'd love it if there was a way to make it so that plugins would work without breaking each new version of ripMIME
- no doubt that's something which really is more dependent on good forward planning and requirements-discovery _before_
implementing.
Regards
--
Paul L Daniels http://www.pldaniels.com
Linux/Unix systems Internet Development
ICQ#103642862,AOL:pldsoftware,IRC:inflex irc.freenode.net
A.B.N. 19 500 721 806