[Bug 24909] Anonymity API (e.g. suppressing caller-ID)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24909

Senko Rasic <senko at senko.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #28 from Senko Rasic <senko at senko.net> 2010-04-30 06:21:33 PDT ---
I've got a branch that implements the proposal from comment #27:

http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/anonymity

The main change is usage of anonymity levels instead of modes. Only three
levels are defined:
  * Anonymity_Level_Public - explicitly allow sending user/network info
  * Anonymity_Level_ClientInfo - hide user and client information
(bikeshedding: maybe this would be better named UserInfo?)
  * Anonymity_Level_NetworkInfo - hide any network-related information, as much
as possible; this implies Anonymity_Level_ClientInfo

There's also Anonymity_Level_None, used by CM to indicate no anonymity services
are supported on the connection, and used by Client when requesting channels to
indicate "use whatever anonymity level the connection has", or when resetting
connection's anonimity to "default" (whatever that may mean for a particular CM
- it will be the same as setting Anonymity_Level_Public explicitly).

This allows us to model GSM use case (Client can request Anonymity_Level_Public
to suppress connection's Anonymity_Level_ClientInfo).

Devil's advocate: since the number of "real" anonymity levels here is small
(2), it might make sense to not complicate things with levels and just have
tristate properties for Anonimity_User_Info and Anonimity_Network_Info (yes,
no, default). It would definitely make it easier for us to add more modes, at
the cost of multiplying the number of properties.

OR, we could have struct AnonimityServices { tristate user_info, tristate
network_info }, so that we can pass it around more easily. The more I think
about levels, the more I like this alternative approach .. levels might be too
complex solution.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.