[Bug 24908] Communication policy (blocking policy) API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #13 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-07-19 11:23:04 PDT ---
(In reply to comment #11)
> (In reply to comment #9)
> > It does seem a shame to define a pair of new types which are basically
> > extensions of Rich_Presence_Access_Control and
> > Rich_Presence_Access_Control_Type...
> 
> I'd like to veto the addition of things that are this similar to RPAC/RPACT,
> but not identical.
> 
> My inclination would be to just use RPAC/RPACT (adding entries as needed), and
> ignore the slightly incorrect naming.
> 

Are there any other consumers besides Location? If not, it seems like a good
opportunity to transition out of the RPAC naming and not have it persist as a
legacy thing forever.

> Alternatively, we could rename RPAC/RPACT, and put compatibility hacks in
> telepathy-glib and telepathy-qt4. I think telepathy-glib can be made compatible
> with a few #defines, but telepathy-qt4 would need a compatibility typedef?
> 
> Another alternative is to keep RPAC/RPACT in the spec, documented as "the same
> as AC/ACT, for backwards compatibility only", and ensure that the two are kept
> exactly in sync.

Both alternatives look like good ideas to me.

> 
> In any case, it's probably premature to add any extra entries that we don't
> have a concrete use-case for, apart from Not_Understood and perhaps Closed.
> Some of the ones I suggested in Comment #5 come from Skype features; Mikhail
> Zabaluev might be able to tell us which ones are needed there.

Which ones specifically?

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