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@1011 | 70 | === Combining Scheduling Functions === |
paul@1011 | 71 | |
paul@1011 | 72 | Extend the resource scheduling support to provide chains of scheduling |
paul@1011 | 73 | functions, as opposed to a single function. Thus, different activities could |
paul@1011 | 74 | be combined. For example, to suggest alternative periods whilst enforcing |
paul@1011 | 75 | booking quotas, there would be two functions indicated in the |
paul@1011 | 76 | `scheduling_function` setting for a resource: |
paul@1011 | 77 | |
paul@1011 | 78 | {{{ |
paul@1011 | 79 | schedule_next_available_in_freebusy |
paul@1011 | 80 | enforce_quota |
paul@1011 | 81 | }}} |
paul@1011 | 82 | |
paul@1011 | 83 | Each function would consider the current state of the event, and the chain |
paul@1011 | 84 | would be terminated if a function decided to decline the participation of |
paul@1011 | 85 | the resource. Otherwise, each function in turn would be able to refine the |
paul@1011 | 86 | event and decide upon the resource's participation. |
paul@1019 | 87 | |
paul@1019 | 88 | == Other Ideas == |
paul@1019 | 89 | |
paul@1019 | 90 | Some more ideas that would be worth pursuing... |
paul@1019 | 91 | |
paul@1019 | 92 | === Mail Client Integration === |
paul@1019 | 93 | |
paul@1019 | 94 | Although the original focus of imip-agent was to produce mail handling |
paul@1019 | 95 | programs that would be [[../MailIntegration|integrated with mail systems]], |
paul@1019 | 96 | some effort has been directed towards making libraries and components that |
paul@1019 | 97 | can be reused in other kinds of programs. Indeed, the |
paul@1019 | 98 | [[../CalendarManager|management interface]] employs the libraries in a |
paul@1019 | 99 | different way from that of the [[../AgentPrograms|agent programs]] and acts |
paul@1019 | 100 | as a kind of calendar client that just happens to use the same |
paul@1019 | 101 | [[../FilesystemUsage|filesystem structures]] to store information and |
paul@1019 | 102 | control the software's behaviour. |
paul@1019 | 103 | |
paul@1019 | 104 | It would therefore be interesting to use the `imiptools` package, possibly |
paul@1019 | 105 | with some modifications, in projects like [[https://mailpile.is/|Mailpile]] |
paul@1019 | 106 | and other Python-based mail clients. And a process-based method of |
paul@1019 | 107 | integration, similar to that employed by the [[../Testing|test suite]], |
paul@1019 | 108 | could benefit even non-Python programs, with imip-agent-based programs |
paul@1019 | 109 | being run to perform certain tasks and to update schedule records that |
paul@1019 | 110 | would then be interpreted independently by the calling programs. |
paul@1019 | 111 | |
paul@1019 | 112 | Where end-to-end encryption is being used for mail communications, such |
paul@1019 | 113 | client integration would be essential for imip-agent to be useful: the |
paul@1019 | 114 | [[../AgentPrograms|agent programs]] are unable to inspect messages without |
paul@1019 | 115 | access to the recipient's secret keys, and unless a recipient is willing |
paul@1019 | 116 | to run their own MTA on their own computer and grant access to various |
paul@1019 | 117 | keys so that the MTA or imip-agent can perform decryption, the only way |
paul@1019 | 118 | that imip-agent might see the actual content would be as part of the |
paul@1019 | 119 | recipient's mail client. |