= Future Plans =

The intention is to continuously improve imip-agent to fix known problems

and to support missing features. Where it makes sense to do so, omissions

in the [[../CalendaringSupport|calendaring support]] should be addressed

as a matter of priority.

Various other areas of improvement are described in the

[[../UseCases|use cases guide]], and the functionality of imip-agent should

be expanded to address such use cases. The intention is that imip-agent go

beyond supporting the manual scheduling of events by providing functionality

to automate scheduling and provisioning, employing readily-adopted tools and

techniques that are adaptable to existing standards-based infrastructure.

See the [[../Developing|development guide]] for more information on

improving imip-agent.

== Specific Plans ==

The following topics are likely to be addressed first:

=== Event Properties ===

The [[../CalendarManager|management interface]] does not expose the full

range of event properties, nor does it allow recurring events to be defined.

Support could be expanded for such properties.

=== Event Limits ===

Being able to specify a frequently-recurring event that has many periods

could cause excessive amounts of free/busy data and make perusal of calendars

very difficult. Certain policies could be supported to avoid this:

 * Reject indefinitely-recurring events

 * Permit certain frequency levels only (for example: hours, days, weeks,

 months, years, but not minutes or seconds)

 * Permit only a certain number of periods per interval (for example: an

 indicated number of periods in a day)

Such limits are orthogonal to quotas because they would apply to all events

created for a user.

=== Quotas ===

To prevent excessive booking of resources and the resulting denial of those

resources, quotas could be introduced. In their most basic form, quotas

would resemble the restrictions imposed by event limits, but would differ

from event limits by imposing such restrictions on a per-user (or other)

basis. Some examples:

  * Permit certain frequency levels depending on the organiser for a

  resource

  * Permit only a certain number of periods per interval depending on the

  organiser (or other property derived from the organiser) for a resource

  or for collections of resources

  * Impose a total limit on the number of active events made by an

  organiser (or other property) for a resource or for collections of

  resources

Where quotas must be coordinated between resources, perhaps on the basis

of groups of users, an external mechanism might need integrating to manage

the activity. Such a mechanism might also support things like billing or

accounting for resources, although this is beyond the scope of imip-agent

itself.

=== Combining Scheduling Functions ===

Extend the resource scheduling support to provide chains of scheduling

functions, as opposed to a single function. Thus, different activities could

be combined. For example, to suggest alternative periods whilst enforcing

booking quotas, there would be two functions indicated in the

`scheduling_function` setting for a resource:

{{{

schedule_next_available_in_freebusy

enforce_quota

}}}

Each function would consider the current state of the event, and the chain

would be terminated if a function decided to decline the participation of

the resource. Otherwise, each function in turn would be able to refine the

event and decide upon the resource's participation.

== Other Ideas ==

Some more ideas that would be worth pursuing...

=== Mail Client Integration ===

Although the original focus of imip-agent was to produce mail handling

programs that would be [[../MailIntegration|integrated with mail systems]],

some effort has been directed towards making libraries and components that

can be reused in other kinds of programs. Indeed, the

[[../CalendarManager|management interface]] employs the libraries in a

different way from that of the [[../AgentPrograms|agent programs]] and acts

as a kind of calendar client that just happens to use the same

[[../FilesystemUsage|filesystem structures]] to store information and

control the software's behaviour.

It would therefore be interesting to use the `imiptools` package, possibly

with some modifications, in projects like [[https://mailpile.is/|Mailpile]]

and other Python-based mail clients. And a process-based method of

integration, similar to that employed by the [[../Testing|test suite]],

could benefit even non-Python programs, with imip-agent-based programs

being run to perform certain tasks and to update schedule records that

would then be interpreted independently by the calling programs.

Where end-to-end encryption is being used for mail communications, such

client integration would be essential for imip-agent to be useful: the

[[../AgentPrograms|agent programs]] are unable to inspect messages without

access to the recipient's secret keys, and unless a recipient is willing

to run their own MTA on their own computer and grant access to various

keys so that the MTA or imip-agent can perform decryption, the only way

that imip-agent might see the actual content would be as part of the

recipient's mail client.