The intention is to continuously improve imip-agent to fix known problems and to support missing features. Where it makes sense to do so, omissions in the calendaring support should be addressed as a matter of priority.
Various other areas of improvement are described in the use cases guide, and the functionality of imip-agent should be expanded to address such use cases. The intention is that imip-agent go beyond supporting the manual scheduling of events by providing functionality to automate scheduling and provisioning, employing readily-adopted tools and techniques that are adaptable to existing standards-based infrastructure.
See the development guide for more information on improving imip-agent.
The following topics are likely to be addressed first:
The management interface does not expose the full range of event properties, nor does it allow recurring events to be defined. Support could be expanded for such properties.
Being able to specify a frequently-recurring event that has many periods could cause excessive amounts of free/busy data and make perusal of calendars very difficult. Certain policies could be supported to avoid this:
Such limits are orthogonal to quotas because they would apply to all events created for a user.
To prevent excessive booking of resources and the resulting denial of those resources, quotas could be introduced. In their most basic form, quotas would resemble the restrictions imposed by event limits, but would differ from event limits by imposing such restrictions on a per-user (or other) basis. Some examples:
Where quotas must be coordinated between resources, perhaps on the basis of groups of users, an external mechanism might need integrating to manage the activity. Such a mechanism might also support things like billing or accounting for resources, although this is beyond the scope of imip-agent itself.
Some more ideas that would be worth pursuing...
Although the original focus of imip-agent was to produce mail handling programs that would be integrated with mail systems, some effort has been directed towards making libraries and components that can be reused in other kinds of programs. Indeed, the management interface employs the libraries in a different way from that of the agent programs and acts as a kind of calendar client that just happens to use the same filesystem structures to store information and control the software's behaviour.
It would therefore be interesting to use the imiptools package, possibly with some modifications, in projects like Mailpile and other Python-based mail clients. And a process-based method of integration, similar to that employed by the test suite, could benefit even non-Python programs, with imip-agent-based programs being run to perform certain tasks and to update schedule records that would then be interpreted independently by the calling programs.
Where end-to-end encryption is being used for mail communications, such client integration would be essential for imip-agent to be useful: the agent programs are unable to inspect messages without access to the recipient's secret keys, and unless a recipient is willing to run their own MTA on their own computer and grant access to various keys so that the MTA or imip-agent can perform decryption, the only way that imip-agent might see the actual content would be as part of the recipient's mail client.