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. |