VZ has an overly complicated concept of GPG usage in email clients. Also -- S/MIME support would be nice, but that topic is orthogonal to GPG, and belongs in its own thread.
ME>> GPG support is a perfect application for Python scripting in ME>> Mahogany. VZ> I don't think so, as it's rather difficult to add full support VZ> for this. Ethically, the M project should remove Python from its web site features list. This feature is the one reason I got interested. Now after "reading the fine print" I learn that Python is no longer supported and unlikely in the future. VZ has all but driven me away from the M project. Without Python scripting, I may as well use any of several dozen email clients, many of which already support GPG/PGP. The ultimate answer to Python scripting may be to port the M project to wxPython. Python scripting is a unique feature and a major selling point. I am tired of half-baked email client "macro" languages. Take Python scripting off the website, and you will not draw any more folks like me to M. Even without full Python support, a simple command-line interface (equivalent to popen2()) could handle GPG. VZ> Apart from simple message decoding/encoding, there are many more VZ> things to VZ> do such as managing the keys, signing (and checking the VZ> signature), ... No. Fancy GUIs are not required. 1) Every operation of GPG is a command-line operation. As long as the user can edit the command-line, all features of GPG are available. 2) GUI-based front-ends to GPG exist for all platforms. Key management per se is not a requirement in M. That is better done by third-party front-ends. 3) Even with a fancy GUI, the user should still have the option to edit the resulting GPG command line. M should simply filter-scan messages for "BEGIN PGP MESSAGE" and trigger a command-line to GPG. For outgoing messages, all you need is a checkbox for GPG encryption and another for GPG signing. These would just add "--encrypt" and "--sign" to the command line. VZ> The problem is not with calling GPG -- this is relatively VZ> trivial. The VZ> problem is to: [worry about code hooks, features, and GUI issues] Python support would solve all of these issues. I made the mistake of taking seriously the website statements about Python having access to M's internal object model. If those statements had been true, then everything could be done from Python. Without Python, I still think we are over-complicating matters. Command-line support for GPG is better than zero support for GPG. Consider a wider perspective. M should offer a command-line pipe interface to support all kinds of external console tools (not just GPG). These tools could be considered as special types of email filters. Since Python support is dying off, at least M should offer a console-tool filtering capability. Then users could run any tool they please -- HTMLTidy, GPG, whatever. Mark ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mahogany-Users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-users
