1.1 --- a/docs/wiki/FuturePlans Fri Nov 06 13:15:31 2015 +0100
1.2 +++ b/docs/wiki/FuturePlans Fri Nov 06 13:52:02 2015 +0100
1.3 @@ -12,5 +12,69 @@
1.4 to automate scheduling and provisioning, employing readily-adopted tools and
1.5 techniques that are adaptable to existing standards-based infrastructure.
1.6
1.7 -See the [[../Development|development guide]] for more information on
1.8 +See the [[../Developing|development guide]] for more information on
1.9 improving imip-agent.
1.10 +
1.11 +== Specific Plans ==
1.12 +
1.13 +The following topics are likely to be addressed first:
1.14 +
1.15 +=== Event Limits ===
1.16 +
1.17 +Being able to specify a frequently-recurring event that has many periods
1.18 +could cause excessive amounts of free/busy data and make perusal of calendars
1.19 +very difficult. Certain policies could be supported to avoid this:
1.20 +
1.21 + * Reject indefinitely-recurring events
1.22 +
1.23 + * Permit certain frequency levels only (for example: hours, days, weeks,
1.24 + months, years, but not minutes or seconds)
1.25 +
1.26 + * Permit only a certain number of periods per interval (for example: an
1.27 + indicated number of periods in a day)
1.28 +
1.29 +Such limits are orthogonal to quotas because they would apply to all events
1.30 +created for a user.
1.31 +
1.32 +=== Quotas ===
1.33 +
1.34 +To prevent excessive booking of resources and the resulting denial of those
1.35 +resources, quotas could be introduced. In their most basic form, quotas
1.36 +would resemble the restrictions imposed by event limits, but would differ
1.37 +from event limits by imposing such restrictions on a per-user (or other)
1.38 +basis. Some examples:
1.39 +
1.40 + * Permit certain frequency levels depending on the organiser for a
1.41 + resource
1.42 +
1.43 + * Permit only a certain number of periods per interval depending on the
1.44 + organiser (or other property derived from the organiser) for a resource
1.45 + or for collections of resources
1.46 +
1.47 + * Impose a total limit on the number of active events made by an
1.48 + organiser (or other property) for a resource or for collections of
1.49 + resources
1.50 +
1.51 +Where quotas must be coordinated between resources, perhaps on the basis
1.52 +of groups of users, an external mechanism might need integrating to manage
1.53 +the activity. Such a mechanism might also support things like billing or
1.54 +accounting for resources, although this is beyond the scope of imip-agent
1.55 +itself.
1.56 +
1.57 +=== Combining Scheduling Functions ===
1.58 +
1.59 +Extend the resource scheduling support to provide chains of scheduling
1.60 +functions, as opposed to a single function. Thus, different activities could
1.61 +be combined. For example, to suggest alternative periods whilst enforcing
1.62 +booking quotas, there would be two functions indicated in the
1.63 +`scheduling_function` setting for a resource:
1.64 +
1.65 +{{{
1.66 +schedule_next_available_in_freebusy
1.67 +enforce_quota
1.68 +}}}
1.69 +
1.70 +Each function would consider the current state of the event, and the chain
1.71 +would be terminated if a function decided to decline the participation of
1.72 +the resource. Otherwise, each function in turn would be able to refine the
1.73 +event and decide upon the resource's participation.