| paul@1007 | 1 | = Future Plans = |
| paul@1007 | 2 | |
| paul@1007 | 3 | The intention is to continuously improve imip-agent to fix known problems |
| paul@1007 | 4 | and to support missing features. Where it makes sense to do so, omissions |
| paul@1007 | 5 | in the [[../CalendaringSupport|calendaring support]] should be addressed |
| paul@1007 | 6 | as a matter of priority. |
| paul@1007 | 7 | |
| paul@1007 | 8 | Various other areas of improvement are described in the |
| paul@1007 | 9 | [[../UseCases|use cases guide]], and the functionality of imip-agent should |
| paul@1007 | 10 | be expanded to address such use cases. The intention is that imip-agent go |
| paul@1007 | 11 | beyond supporting the manual scheduling of events by providing functionality |
| paul@1007 | 12 | to automate scheduling and provisioning, employing readily-adopted tools and |
| paul@1007 | 13 | techniques that are adaptable to existing standards-based infrastructure. |
| paul@1007 | 14 | |
| paul@1011 | 15 | See the [[../Developing|development guide]] for more information on |
| paul@1007 | 16 | improving imip-agent. |
| paul@1011 | 17 | |
| paul@1011 | 18 | == Specific Plans == |
| paul@1011 | 19 | |
| paul@1011 | 20 | The following topics are likely to be addressed first: |
| paul@1011 | 21 | |
| paul@1015 | 22 | === Event Properties === |
| paul@1015 | 23 | |
| paul@1015 | 24 | The [[../CalendarManager|management interface]] does not expose the full |
| paul@1015 | 25 | range of event properties, nor does it allow recurring events to be defined. |
| paul@1015 | 26 | Support could be expanded for such properties. |
| paul@1015 | 27 | |
| paul@1011 | 28 | === Event Limits === |
| paul@1011 | 29 | |
| paul@1011 | 30 | Being able to specify a frequently-recurring event that has many periods |
| paul@1011 | 31 | could cause excessive amounts of free/busy data and make perusal of calendars |
| paul@1011 | 32 | very difficult. Certain policies could be supported to avoid this: |
| paul@1011 | 33 | |
| paul@1011 | 34 | * Reject indefinitely-recurring events |
| paul@1011 | 35 | |
| paul@1011 | 36 | * Permit certain frequency levels only (for example: hours, days, weeks, |
| paul@1011 | 37 | months, years, but not minutes or seconds) |
| paul@1011 | 38 | |
| paul@1011 | 39 | * Permit only a certain number of periods per interval (for example: an |
| paul@1011 | 40 | indicated number of periods in a day) |
| paul@1011 | 41 | |
| paul@1011 | 42 | Such limits are orthogonal to quotas because they would apply to all events |
| paul@1011 | 43 | created for a user. |
| paul@1011 | 44 | |
| paul@1011 | 45 | === Quotas === |
| paul@1011 | 46 | |
| paul@1011 | 47 | To prevent excessive booking of resources and the resulting denial of those |
| paul@1011 | 48 | resources, quotas could be introduced. In their most basic form, quotas |
| paul@1011 | 49 | would resemble the restrictions imposed by event limits, but would differ |
| paul@1011 | 50 | from event limits by imposing such restrictions on a per-user (or other) |
| paul@1011 | 51 | basis. Some examples: |
| paul@1011 | 52 | |
| paul@1011 | 53 | * Permit certain frequency levels depending on the organiser for a |
| paul@1011 | 54 | resource |
| paul@1011 | 55 | |
| paul@1011 | 56 | * Permit only a certain number of periods per interval depending on the |
| paul@1011 | 57 | organiser (or other property derived from the organiser) for a resource |
| paul@1011 | 58 | or for collections of resources |
| paul@1011 | 59 | |
| paul@1011 | 60 | * Impose a total limit on the number of active events made by an |
| paul@1011 | 61 | organiser (or other property) for a resource or for collections of |
| paul@1011 | 62 | resources |
| paul@1011 | 63 | |
| paul@1011 | 64 | Where quotas must be coordinated between resources, perhaps on the basis |
| paul@1011 | 65 | of groups of users, an external mechanism might need integrating to manage |
| paul@1011 | 66 | the activity. Such a mechanism might also support things like billing or |
| paul@1011 | 67 | accounting for resources, although this is beyond the scope of imip-agent |
| paul@1011 | 68 | itself. |
| paul@1011 | 69 | |
| paul@1019 | 70 | == Other Ideas == |
| paul@1019 | 71 | |
| paul@1019 | 72 | Some more ideas that would be worth pursuing... |
| paul@1019 | 73 | |
| paul@1019 | 74 | === Mail Client Integration === |
| paul@1019 | 75 | |
| paul@1019 | 76 | Although the original focus of imip-agent was to produce mail handling |
| paul@1019 | 77 | programs that would be [[../MailIntegration|integrated with mail systems]], |
| paul@1019 | 78 | some effort has been directed towards making libraries and components that |
| paul@1019 | 79 | can be reused in other kinds of programs. Indeed, the |
| paul@1019 | 80 | [[../CalendarManager|management interface]] employs the libraries in a |
| paul@1019 | 81 | different way from that of the [[../AgentPrograms|agent programs]] and acts |
| paul@1019 | 82 | as a kind of calendar client that just happens to use the same |
| paul@1019 | 83 | [[../FilesystemUsage|filesystem structures]] to store information and |
| paul@1019 | 84 | control the software's behaviour. |
| paul@1019 | 85 | |
| paul@1019 | 86 | It would therefore be interesting to use the `imiptools` package, possibly |
| paul@1019 | 87 | with some modifications, in projects like [[https://mailpile.is/|Mailpile]] |
| paul@1019 | 88 | and other Python-based mail clients. And a process-based method of |
| paul@1019 | 89 | integration, similar to that employed by the [[../Testing|test suite]], |
| paul@1019 | 90 | could benefit even non-Python programs, with imip-agent-based programs |
| paul@1019 | 91 | being run to perform certain tasks and to update schedule records that |
| paul@1019 | 92 | would then be interpreted independently by the calling programs. |
| paul@1019 | 93 | |
| paul@1019 | 94 | Where end-to-end encryption is being used for mail communications, such |
| paul@1019 | 95 | client integration would be essential for imip-agent to be useful: the |
| paul@1019 | 96 | [[../AgentPrograms|agent programs]] are unable to inspect messages without |
| paul@1019 | 97 | access to the recipient's secret keys, and unless a recipient is willing |
| paul@1019 | 98 | to run their own MTA on their own computer and grant access to various |
| paul@1019 | 99 | keys so that the MTA or imip-agent can perform decryption, the only way |
| paul@1019 | 100 | that imip-agent might see the actual content would be as part of the |
| paul@1019 | 101 | recipient's mail client. |
