Even if RoleIds were cached in the cookie (instead of using the names themselves), this would only increase the number of persistable roles to between 63 and 85 (minus encryption-added overhead).  For a corner case, I doubt many would see this as a worthwhile venture. 

A better solution would be to use a per-portal, ~255 byte bitfield-based cookie, allowing ~2000 roles per-portal (minus encryption overhead).  This introduces additional complexity (on role deletions, mostly) and again seems unlikely given the majority viewpoint on the utility of a solution with many roles.  It could be architectured to be more performant than the current system, however.

Brandon

Edit: For some reason I got it in my head that 260 characters was a maximum cookie length; this is in fact the maximum URI length (in some browsers).  My roleId-storage discussion thusly becomes invalid, with a general maximum number of storable roles between 500 - 650.  The bitfield is still the more performant choice (in addition to allowing ~16k roles per-portal, albeit potentially not worth the ondelete-invalidation hassle).

In general, I completely agree.  I get to throw out wild architectural design changes because I neither have to implement them nor ensure they continue to support legacy scenarios :)

I thought I'd add that because, in general, a role-based bitfield could be treated as a sparsely populated vector, it could be represented in memory much more efficiently than (loosely) O(n) space.  Although a worst-case might be 16k roles, there would in practice be essentially no maximum (assuming sparse assignment).  Spare matrices are well-studied in the academic literature.

Role deserialization in a bitfield data structure would be much more efficient than through iterative string manipulation, as well (regardless of whether name matching or string-to-integer roleId conversion were used).

Given that the general consensus seems to be that high-volume role support is not a viable use-case in DNN, these implementation details become purely academic (but interesting!). 

Brandon