1 = Future Plans = 2 3 The intention is to continuously improve imip-agent to fix known problems 4 and to support missing features. Where it makes sense to do so, omissions 5 in the [[../CalendaringSupport|calendaring support]] should be addressed 6 as a matter of priority. 7 8 Various other areas of improvement are described in the 9 [[../UseCases|use cases guide]], and the functionality of imip-agent should 10 be expanded to address such use cases. The intention is that imip-agent go 11 beyond supporting the manual scheduling of events by providing functionality 12 to automate scheduling and provisioning, employing readily-adopted tools and 13 techniques that are adaptable to existing standards-based infrastructure. 14 15 See the [[../Developing|development guide]] for more information on 16 improving imip-agent. 17 18 == Specific Plans == 19 20 The following topics are likely to be addressed first: 21 22 === Event Limits === 23 24 Being able to specify a frequently-recurring event that has many periods 25 could cause excessive amounts of free/busy data and make perusal of calendars 26 very difficult. Certain policies could be supported to avoid this: 27 28 * Reject indefinitely-recurring events 29 30 * Permit certain frequency levels only (for example: hours, days, weeks, 31 months, years, but not minutes or seconds) 32 33 * Permit only a certain number of periods per interval (for example: an 34 indicated number of periods in a day) 35 36 Such limits are orthogonal to quotas because they would apply to all events 37 created for a user. 38 39 === Quotas === 40 41 To prevent excessive booking of resources and the resulting denial of those 42 resources, quotas could be introduced. In their most basic form, quotas 43 would resemble the restrictions imposed by event limits, but would differ 44 from event limits by imposing such restrictions on a per-user (or other) 45 basis. Some examples: 46 47 * Permit certain frequency levels depending on the organiser for a 48 resource 49 50 * Permit only a certain number of periods per interval depending on the 51 organiser (or other property derived from the organiser) for a resource 52 or for collections of resources 53 54 * Impose a total limit on the number of active events made by an 55 organiser (or other property) for a resource or for collections of 56 resources 57 58 Where quotas must be coordinated between resources, perhaps on the basis 59 of groups of users, an external mechanism might need integrating to manage 60 the activity. Such a mechanism might also support things like billing or 61 accounting for resources, although this is beyond the scope of imip-agent 62 itself. 63 64 === Combining Scheduling Functions === 65 66 Extend the resource scheduling support to provide chains of scheduling 67 functions, as opposed to a single function. Thus, different activities could 68 be combined. For example, to suggest alternative periods whilst enforcing 69 booking quotas, there would be two functions indicated in the 70 `scheduling_function` setting for a resource: 71 72 {{{ 73 schedule_next_available_in_freebusy 74 enforce_quota 75 }}} 76 77 Each function would consider the current state of the event, and the chain 78 would be terminated if a function decided to decline the participation of 79 the resource. Otherwise, each function in turn would be able to refine the 80 event and decide upon the resource's participation.