From: Mark D. <ma...@ki...> - 2005-02-06 16:56:12
|
On Sat, 5 Feb 2005 01:37:46 -0600, Felipe Contreras wrote > Hi everybody. > > As some of you alredy know, I've been working on rewriting the > privacy API. At first I just wanted to add a block/unblock menu icon > in the buddy menu, but I found a lot of problems doing so, so I > started this thing. > > The main problem with privacy, as well as status, is that it's very > aim centric, probably much more, but it goes beyond, you can't know > for example, if a buddy is blocked or not that easily. How is the status code AIM-centric? > So the first thing is to remove permit/deny lists, in fact, remove > the concept of lists, if the prpl is going to state wether it can > permit, deny, or none of those, or even set someone as visible; > lists are something not very extensible for that matter. I disagree. > gaim_account_new_dude_mode (account, "connection", "online"); > gaim_account_new_dude_mode (account, "connection", "offline"); > gaim_account_new_dude_mode (account, "status", "available"); > gaim_account_new_dude_mode (account, "status", "busy"); > gaim_account_new_dude_mode (account, "status", "brb"); > gaim_account_new_dude_mode (account, "status", "away"); > gaim_account_new_dude_mode (account, "status", "hidden"); > gaim_account_new_dude_mode (account, NULL, "permitted"); > gaim_account_new_dude_mode (account, NULL, "denied"); This looks like it duplicates a lot of stuff from the status API for no real reason. > Also, considering the current status rewrite, I think there is too > much UI code inside of structures that shouldn't be that complex. For > example, how many protocols are going to change the _("Availabe") > name for the "available" status? Shouldn't this be something the UI > decide? or at least shouldn't be used at all when deciding if a dude > is online. Maybe there can be something like > gaim_account_add_custom_status, but that will should be used by the UI. Every UI should not have to figure out what to call the "available" status. If it's set once in the core or PRPLs then all UIs will call it the same thing. Consistency is a good thing. And UIs could still use something else if they wanted. Overall I don't see any real benefit to any of these changes... For the privacy API, we need a new structure. Maybe GaimPrivacyList. Protocols will define these when they're initialized, similar to how the GaimStatusType structures are created. Each GaimPrivacyList should have a name ("Permit," "Deny," "Ignore," etc.) The name should be whatever is appropriate for each protocol. It should have a list of the people that are blocked or allowed or whatever. Then UIs could show only the lists appropriate for each protocol. So MSN would have only an "Allow" list. Does that make sense? -Mark |