Informal raising of issue on context-service/-manager

["Green, Alastair J." <Alastair.Green@choreology.com>]

Will figure out how to put this into Bugzilla depending on further
thought from the committee, but for the moment:

In yesterday's meeting I was actioned to describe a possible change
proposal to amplify/streamline an aspect of ContextType.

Problem: context-service and context-manager are two facets (interfaces)
of the same beast (the Context Service).

Problem: discussion on by-ref/by-val, and decision to make
context-service dereferenceable raised issue of access control.
Availability of context-service implies either ability to inquire
status, or issue complete. Availability/presence of context-manager
implies either ability to dereference (read) or mutate (write) contents.

Strawman proposal for further thinking:

Have one ServiceRefType element, called context-service.

Have some scheme of flags: accessible, mutable, status-inquirable,
completable. Setting of same, by Context Service on emission of a
context, would govern intended legal operations by context holder on the
context service. E.g. I give you this context, you cannot change it, you
can inquire on the activity's status, you cannot end the activity.

Problem: for enforcement, would require retention of identity of
recipient. But contexts escape into the wild. So this could only be
advisory?

Alternative: replace crude "access control" represented by presence or
absence of the two references, by a single reference, which would
support all four operations (get, set, status inquiry, complete). Find
out by faulting which ones make sense for the issuer.

This is an ill-thought out first pass on the access control issue, that
I believe probably needs a bit more precision in any event.

Hope this captures the discussion and is useful.

Alastair