From: Felipe C. <fel...@gm...> - 2005-02-05 07:37:48
|
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. 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. So here comes the first new concept, a "mode". A mode is simply something a buddy has, like "permit" or "deny", and a buddy can have a many as the prpl allows, and they can be on or off. In fact, it can be extended to have a certain vvalue, like an int, for warning levels or idle time, or it may even have a timestamp to know where did we last see that buddy, allowing all kind of crazy things. For now, simply knowing if the mode is on/off should be enough. I know what some of you are surely thinking, we usually block non-buddies. So we need a new structure to store those privacy modes. This structure GaimWatever, should have unique objects for each screename in a certain account, so, it's id is "account, screename". I called this structure GaimDude, which can be easily changed. But then I noticed how similar a GaimDude is to a GaimPresence, at least for buddies, since a GaimPresence is also valid for accounts, and chats. And then after some thinking I came to this code: 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"); So, there are two kind of modes, the dependent, and the independent. Basically one can be both "permitted" and "denied", bot not "brb" and "away". Two modes that are in the same mode group can't be _on_ at the same time. I made this as efficiently as possible, and for that, there can't be two modes with the same name. You need to see the code in order to understand what I mean. But it's pretty much simpler that way, you just ask: is this dude "busy"?, is this dude "permitted"?, stuff like that. 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. And, those modes can be extended also to an account: gaim_account_new_mode (account, "connection", "online"); gaim_account_new_mode (account, "connection", "offline"); gaim_account_new_mode (account, "status", "available"); gaim_account_new_mode (account, "status", "busy"); gaim_account_new_mode (account, "status", "brb"); gaim_account_new_mode (account, "status", "away"); gaim_account_new_mode (account, "status", "hidden"); gaim_account_new_mode (account, "privacy", "allow users"); gaim_account_new_mode (account, "privacy", "block users"); gaim_account_new_mode (account, "privacy", "allow blist"); So the prpl can say gaim_prpl_account_got_mode_on (account, "allow users"), and that's all. That is simple and extensible, the UI can decide what to do with each GaimModeSet for the structures that have one, and Gaim core can assume certain basic modes like "permitted" that if set should generate a know behaviour if a buddy has it set. Don't forget to think how easier will be to save modes into blist.xml, of course, we may need to add a flag to know if we should store it. Anyway, I'm not sure how good can this work for buddy status, and I'm even less sure about account status, but I've alredy coded this thing for privacy in sorta unclean way, and it works great. I still need to work on the privacy settings dialog that has some old code of mine before I got this idea. It should be pretty straightforward but I think I'll first clean up all this mess in order to make an acceptable patch, and to know your opinions. So what do you think? -- Felipe Contreras |
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 |
From: Felipe C. <fel...@gm...> - 2005-02-06 18:37:45
|
On Sun, 6 Feb 2005 11:56:03 -0500, Mark Doliner <ma...@ki...> wrote: > 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? Yahoo only has invisible capability, and no "permit/deny" setting. MSN only has block/allow per buddy setting, and default block, default allow. Jabber only has authorized, not authorized per buddy modes. ICQ has permit/deny/visible/custom per buddy settings, and some more account privacy settings. Novell also, is like MSN. A lot doesn't even have privacy stuff. > > 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. It's a purposed new way of handling status, instead of the current API. As Sean suggested that there could be a better one, this is one way, for starters, that is much more efficient in doing it's core job. > > 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. I'm a little bit confused. You are in favour of consistency in all of our future UI's, but right now each PRPL can have a different name for a GAIM_STATUS_AVAILABLE, making a single UI possibly inconsistent. However, GaimCore can map showable names for the common "modes", and PRPL's can map custom "modes". But those are showable name mode mappings, nothing to do with the real bulk of the privacy objective, that is get/set per buddy modes and privacy settings. > 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? So, each time we want to display a buddy icon, or make a buddy menu, we have search for the buddy in the buddy list, then we have to search in the "permit" or "deny" lists, and if the PRPL requires it it will have to search each and every one of the relevant lists. Wouldn't it be easier, and wiser, to search once, and then retrieve the relevant buddy modes? Now, in which PrivacyList does the warning level falls? And what about the custom "Show As" mode that ICQ Allows? we will have "show as busy" "show as offline" "show as away" PrivacyLists's? And what if we on top of that, we add client/side blockings, as it's being each time more necessary? We will have to add a "client block" PrivacyList, and search one more time again each time we want to show a buddy icon, or buddy menu. In fact, even if we use PrivacyLists for handling dude modes, the API for get/set a dude mode will be the same, just that instead of retrieving a buddy mode, we search in the relevant PrivacyList for that mode. But you are not giving any feedback about how to deal with privacy settings. AIM for example can have "Block All", but it may not be the only prpl to allow that. Is each and every PRPL going to have to define what "Block All" is? And what about "Block Users"? Should each PRPL going to have to decide what to do with that privacy setting? and even change it's showable name? What about "Ignore chat requests" or "Require Authorization", how does the current API allows PRPLs to set these modes, or any custom mode for that matter? Also, there is the thing that GaimPresence is basically the same as my purposed GaimDude. Both are trying to achieve the goal of storing per account/screenname data. What makes PrivacyLists so suitable and makes StatusLists unsuitable? The only real difference between Privacy, and Status, is that we don't often search for buddies in a certain status, and also, we don't have all our buddies, in a PrivacyList. But that's just because our current way of handling things, some UI may decide to group buddies by status, or as someone suggested to only show Available buddies, or as many MSN users would like, to group buddies by "Online"/"Offline". In summary, please think a little bit more about the "mode" API, one is my implementation, but the other one could be trough PrivacyLists, the thing is to detect the mode of a certain dude and I think the API works. Also, don't be so hasty to throw away my ideas, I already coded something pretty similar to the new status API, that's why I don't think it's so good and I came up with this. Besides, I already coded GaimDude with GObject, and a lot of neat things seems to be possible, like to activate a signal when a specific mode is set on/off. PrivacyLists seems to a waste of space to me. -- Felipe Contreras |
From: Mark D. <ma...@ki...> - 2005-02-06 20:32:32
|
On Sun, 6 Feb 2005 12:37:42 -0600, Felipe Contreras wrote > On Sun, 6 Feb 2005 11:56:03 -0500, Mark Doliner <ma...@ki...> wrote: > > On Sat, 5 Feb 2005 01:37:46 -0600, Felipe Contreras wrote > > > 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? > > Yahoo only has invisible capability, and no "permit/deny" setting. > MSN only has block/allow per buddy setting, and default block, > default allow. Jabber only has authorized, not authorized per buddy modes. > ICQ has permit/deny/visible/custom per buddy settings, and some more > account privacy settings. > Novell also, is like MSN. > A lot doesn't even have privacy stuff. Everything you listed deals with privacy. I asked about status. And even if the things you listed were status-related, it still wouldn't answer my question. > > This looks like it duplicates a lot of stuff from the status API for no real reason. > > It's a purposed new way of handling status, instead of the current > API. As Sean suggested that there could be a better one, this is one > way, for starters, that is much more efficient in doing it's core job. It doesn't seem more efficient to me, and it seems a lot harder to understand. It just doesn't feel natural. For one thing, status types and the status info about buddies is not saved anywhere--it is re-created when you sign on and destroyed when you sign off. Privacy lists are maintained (either locally or on a server). Privacy decides whether other buddies are allowed to see you in their buddy list or not, on a per-buddy scale. Status deals with the away-state of everyone in your buddy list, and it deals with how you appear to people, in general. (It is of course a bit more complicated than that.) > > > 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. > > I'm a little bit confused. You are in favour of consistency in all of > our future UI's, but right now each PRPL can have a different name > for a GAIM_STATUS_AVAILABLE, making a single UI possibly inconsistent. Consistency across PRPLs and consistency across UIs are completely different ideas. > However, GaimCore can map showable names for the common "modes", and > PRPL's can map custom "modes". But those are showable name mode > mappings, nothing to do with the real bulk of the privacy objective, > that is get/set per buddy modes and privacy settings. > > > 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? > > So, each time we want to display a buddy icon, or make a buddy menu, > we have search for the buddy in the buddy list, then we have to > search in the "permit" or "deny" lists, and if the PRPL requires it > it will have to search each and every one of the relevant lists. > Wouldn't it be easier, and wiser, to search once, and then retrieve > the relevant buddy modes? > > Now, in which PrivacyList does the warning level falls? And what > about the custom "Show As" mode that ICQ Allows? we will have "show > as busy" "show as offline" "show as away" PrivacyLists's? > > And what if we on top of that, we add client/side blockings, as it's > being each time more necessary? We will have to add a "client block" > PrivacyList, and search one more time again each time we want to show > a buddy icon, or buddy menu. > > In fact, even if we use PrivacyLists for handling dude modes, the API > for get/set a dude mode will be the same, just that instead of > retrieving a buddy mode, we search in the relevant PrivacyList for > that mode. > > But you are not giving any feedback about how to deal with privacy > settings. AIM for example can have "Block All", but it may not be the > only prpl to allow that. Is each and every PRPL going to have to > define what "Block All" is? And what about "Block Users"? Should each > PRPL going to have to decide what to do with that privacy setting? > and even change it's showable name? Yes, every PRPL should define what "Block All" is. It's not that complicated. You could call something like gaim_privacy_list_new(), and pass arguments saying whether the privacy state should have a list of people or not, the name of the privacy state, maybe an enum like GAIM_PRIVACY_BLOCK for block lists, and maybe a boolean for whether the privacy state is exclusive or not. In fact, this is EXTREMELY similar to how status is done. > What about "Ignore chat requests" or "Require Authorization", how > does the current API allows PRPLs to set these modes, or any custom mode > for that matter? Huh? We haven't talked about either of these at all, I don't see how they would sway this argument one way or the other. Personally I don't think we need an "Ignore chat requests" option. I don't really care how "Require Authorization" is handled. -Mark |
From: Felipe C. <fel...@gm...> - 2005-02-06 21:22:53
|
On Sun, 6 Feb 2005 15:32:23 -0500, Mark Doliner <ma...@ki...> wrote: > On Sun, 6 Feb 2005 12:37:42 -0600, Felipe Contreras wrote > > Yahoo only has invisible capability, and no "permit/deny" setting. > > MSN only has block/allow per buddy setting, and default block, > > default allow. Jabber only has authorized, not authorized per buddy modes. > > ICQ has permit/deny/visible/custom per buddy settings, and some more > > account privacy settings. > > Novell also, is like MSN. > > A lot doesn't even have privacy stuff. > > Everything you listed deals with privacy. I asked about status. And even if > the things you listed were status-related, it still wouldn't answer my question. Sorry, my bad. I tried to say privacy code is AIM centric, status code _was_ AIM centric. Then I mixed both in my mind. > > > This looks like it duplicates a lot of stuff from the status API for no > real reason. > > > > It's a purposed new way of handling status, instead of the current > > API. As Sean suggested that there could be a better one, this is one > > way, for starters, that is much more efficient in doing it's core job. > > It doesn't seem more efficient to me, and it seems a lot harder to understand. > It just doesn't feel natural. For one thing, status types and the status > info about buddies is not saved anywhere--it is re-created when you sign on > and destroyed when you sign off. Privacy lists are maintained (either locally > or on a server). Privacy decides whether other buddies are allowed to see you > in their buddy list or not, on a per-buddy scale. Status deals with the > away-state of everyone in your buddy list, and it deals with how you appear to > people, in general. (It is of course a bit more complicated than that.) People have get confused all the time because they don't have good feedback about which buddies they have blocked (specially MSN users, of course). That's because once you see the privacy mode of a buddy in it's tooltip, it gets more obvious a privacy setting it's more like a manually set status. If all of your buddies (dudes in your list) have the same privacy mode, then then privacy mode is more just like a block list. If that was the case I would agree with you. But it's not, people want to have all weird kinds of privacy modes, and they want them to be easily viewable and changeable. Also, I thought one of the considerations of the status rewrite was to allow login in last Status. In that case we need to save our status, that is a manually set "thing" that gets saved. Now think about RL. That flag that MSN dudes have that states if a dude has you on his buddy list. Note that I'm talking about dudes, because there are persons that have you, but you don't have them. What is this? a status? a mode? Do we need a PrivacyList for that? What if the user wants to see all his RL dudes, or maybe only the ones that are not on his buddy list? Think about it, you can just say that's stupid, because for MSN users it would be a good feature, and surely someone would like to make a plugin for that. If we can allow that, we are being _extensible_. > > > > 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. > > > > I'm a little bit confused. You are in favour of consistency in all of > > our future UI's, but right now each PRPL can have a different name > > for a GAIM_STATUS_AVAILABLE, making a single UI possibly inconsistent. > > Consistency across PRPLs and consistency across UIs are completely different > ideas. Of course, but I don't see why it's more important consistency across UIs than consistency across PRPLs. > > However, GaimCore can map showable names for the common "modes", and > > PRPL's can map custom "modes". But those are showable name mode > > mappings, nothing to do with the real bulk of the privacy objective, > > that is get/set per buddy modes and privacy settings. > > > > > 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? > > > > So, each time we want to display a buddy icon, or make a buddy menu, > > we have search for the buddy in the buddy list, then we have to > > search in the "permit" or "deny" lists, and if the PRPL requires it > > it will have to search each and every one of the relevant lists. > > Wouldn't it be easier, and wiser, to search once, and then retrieve > > the relevant buddy modes? > > > > Now, in which PrivacyList does the warning level falls? And what > > about the custom "Show As" mode that ICQ Allows? we will have "show > > as busy" "show as offline" "show as away" PrivacyLists's? > > > > And what if we on top of that, we add client/side blockings, as it's > > being each time more necessary? We will have to add a "client block" > > PrivacyList, and search one more time again each time we want to show > > a buddy icon, or buddy menu. > > > > In fact, even if we use PrivacyLists for handling dude modes, the API > > for get/set a dude mode will be the same, just that instead of > > retrieving a buddy mode, we search in the relevant PrivacyList for > > that mode. > > > > But you are not giving any feedback about how to deal with privacy > > settings. AIM for example can have "Block All", but it may not be the > > only prpl to allow that. Is each and every PRPL going to have to > > define what "Block All" is? And what about "Block Users"? Should each > > PRPL going to have to decide what to do with that privacy setting? > > and even change it's showable name? > > Yes, every PRPL should define what "Block All" is. It's not that complicated. > You could call something like gaim_privacy_list_new(), and pass arguments > saying whether the privacy state should have a list of people or not, the name > of the privacy state, maybe an enum like GAIM_PRIVACY_BLOCK for block lists, > and maybe a boolean for whether the privacy state is exclusive or not. In > fact, this is EXTREMELY similar to how status is done. The point is not the complication, I'm sure if we have 10 PRPLs that allow the "Block users" privacy option the 10 of them can just copy paste the same lines, the point is: for what? Consider this approach: Core: The core assumes there are some official dude modes, like "permitted", "dennied". The PRPL needs a new one, like "visible". So it states it this way to the Core. gaim_account_new_dude_mode(account, NULL, "permitted"); gaim_account_new_dude_mode(account, NULL, "denied"); gaim_account_new_dude_mode(account, NULL, "visible"); Then the core in it's gaim_dude_is_blocked function can check: gaim_dude_mode_is_on(dude, "permitted") and so, in order to determine if a dude is blocked or not. Of course, when setting getting dude's mode it should be checked first if the account allows that. Ok, now, what else do you need? you will probably need action mappings, which should be pretty straighforward. "permitt" -> _("Permit") "denied" -> _("Deny") Can those be done in the core?, absolutely. What if the PRPL wants it's custom mode to be in the buddy menu? The prpl can add a action mapping, _and_ it will need to add a buddy menu entry. "visible" -> _("Visible") gaim_account_add_dude_mode_entry ("visible"); Now, will someone want to have "Permit" and "Deny" in the buddy menu entry? Of course not, the only thing you care is to block/allow a dude, and probably some custom modes like this one. That's basically all you'll need for dude modes. Why to add this "UI" bulk to the PRPLs unnecesarily? If they need special modes in the UI they can add them, but the Core can have official ones. Of course account privacy settings are something totally different, and I can go on and writte all about this if you like. > > What about "Ignore chat requests" or "Require Authorization", how > > does the current API allows PRPLs to set these modes, or any custom mode > > for that matter? > > Huh? We haven't talked about either of these at all, I don't see how they > would sway this argument one way or the other. Personally I don't think we > need an "Ignore chat requests" option. I don't really care how "Require > Authorization" is handled. Well, maybe you haven't, maybe I haven't, but that doesn't mean PRPLs aren't going to need special per account privacy settings. Why not just let them? In fact I think MSN has a client side option to "don't require auth", but I've never bothered to add it. -- Felipe Contreras |
From: Luke S. <lsc...@us...> - 2005-02-06 20:10:12
|
On Sun, Feb 06, 2005 at 11:56:03AM -0500, Mark Doliner wrote: > 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? the current code in cvs HEAD is not AIM-centric, but i suspect that when shx says "current," he means 1.x. > > > 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. icq would use at least 3 lists. aim uses 2. jabber would need at least 2, but different ones than aim does. I do not know much about the other protocols. this code DOES duplicate a significant amount if looked at in parallel to cvs HEAD. it is meant more as a replacement. > > > 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. for available this works, but for away it does not. what you describe is exactly what we are currently doing for away, and most people agree that it is not ideal. > > 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 we need far more than *a* privacy list. _I_ argue that privacy is inherently integrated with status, something that you can see from some of the more "advanced" stuff that icq allows, as well as some of the stuff that jabber allows (both let you go invisible to a single person, icq lets you go "away" or "na" to a single person). Shx appears to be taking my approach in that he has combined them. > 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 that would work, I do not know to what extent it would be intuitive. our tools->privacy is not, apparently, many people only find it after being told about it, and (because it IS aim-centric), few understand it then. while the understanding of it could, and almost certainly would, be improved by this approach, i do not know that it would be more found. luke |
From: Mark D. <ma...@ki...> - 2005-02-06 20:36:23
|
On Sun, 6 Feb 2005 15:10:09 -0500, Luke Schierer wrote > On Sun, Feb 06, 2005 at 11:56:03AM -0500, Mark Doliner wrote: > > On Sat, 5 Feb 2005 01:37:46 -0600, Felipe Contreras wrote > > > 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. > > for available this works, but for away it does not. what you > describe is exactly what we are currently doing for away, and most > people agree that it is not ideal. Why doesn't it work for away? > > 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 > > we need far more than *a* privacy list. _I_ argue that privacy is > inherently integrated with status, something that you can see from > some of the more "advanced" stuff that icq allows, as well as some > of the stuff that jabber allows (both let you go invisible to a > single person, icq lets you go "away" or "na" to a single person). > Shx appears to be taking my approach in that he has combined them. I never said we should only have *a* privacy list. Also, I really don't think ICQ lets you go "away" or "na" to a single person. You're going to have to show me a screenshot of the Windows ICQ client preferences for this for me to believe otherwise. If Jabber DOES allow this, I'm still not sure that's reason enough to combine status and privacy. It seems like a bad idea to me. -Mark |
From: Mark D. <ma...@ki...> - 2005-02-07 22:43:30
|
On Mon, 7 Feb 2005 09:28:55 -0500, Luke Schierer wrote > On Sun, Feb 06, 2005 at 03:36:15PM -0500, Mark Doliner wrote: > > On Sun, 6 Feb 2005 15:10:09 -0500, Luke Schierer wrote > > > On Sun, Feb 06, 2005 at 11:56:03AM -0500, Mark Doliner wrote: > > > > On Sat, 5 Feb 2005 01:37:46 -0600, Felipe Contreras wrote > > > > > > for available this works, but for away it does not. what you > > > describe is exactly what we are currently doing for away, and most > > > people agree that it is not ideal. > > > > Why doesn't it work for away? > > As things stand in 1.x, you cannot go globally away and have an icq > account be "na". you cannot go to "na" and have a custom message. > this is because if you have the core only aware of certain concepts > that trancend the various protocols, you force a lowwest common > denominator in which we have decided that "away" for icq always > means "away" and never "na" even though both are in fact away (not > online). mmm this is getting confused by the fact that icq has an > actuall state called away. hopefully you can still follow. > > this is not ideal because "na" is essentially a more extreme form of > away and "away" a mild form of away, and either might be more > applicable at different times if a the ui could allow a more > heuristic approach, or a more user controled one. however, since > many protocols do not offer this complexity, our 1.x ui forces the > protocol to define what away is (note the string away is gaim-core > and "away" is an icq state). this relates directly to privacy in > that this is exactly what you want to force, a lowwest common denominator. > > in 2.x we are working on a ui that will (as things stand) default to > the same lowest common denominator approach described abovel, but > will allow a user to determine that "na" and not "away" is the > correct mapping for a given away state. I believe that privacy needs > to have similar flexibility. I don't believe we're talking about 1.x. I certainly am not. I would hope Felipe also is not. I'm not sure why you would think rewriting the privacy API would be something that would go into 1.x. -Mark |
From: Luke S. <lsc...@us...> - 2005-02-07 22:48:21
|
On Mon, Feb 07, 2005 at 05:43:18PM -0500, Mark Doliner wrote: > > I don't believe we're talking about 1.x. I certainly am not. I would hope > Felipe also is not. I'm not sure why you would think rewriting the privacy > API would be something that would go into 1.x. > > -Mark I am not saying that a privacy api change would go into 1.x, I am, across my emails in this thread, comparing the UI presented, and what it is capable of in 1.x as it will remain, in 2.0.0cvs as it stands, and what I would like to see gaim be able to do. luke |
From: Luke S. <lsc...@us...> - 2005-02-07 22:58:13
|
Specifically, above, I was drawing a comparison between what you have proposed (that the core only be aware of certain privacy states, and the protocols translate them into some predefined, protocol supported state) to the way status worked in 1.x, and why we rejected the same sort of abstraction there. luke |
From: Mark D. <ma...@ki...> - 2005-02-07 23:14:36
|
On Mon, 7 Feb 2005 17:58:10 -0500, Luke Schierer wrote > Specifically, above, I was drawing a comparison between what you > have proposed (that the core only be aware of certain privacy states, > and the protocols translate them into some predefined, protocol > supported state) to the way status worked in 1.x, and why we > rejected the same sort of abstraction there. > > luke Is this addressed to me? I never suggested any sort of translation between a predefined status type and a protocol status type. I think the way it's done in CVS head right now works well. And previously you said that allowing PRPLs to choose the user-visible name for, e.g. the occupied status would not work. Here's how the conversation went. Felipe said: > 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. Then I said: > 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. Then, for some reason, you said: > for available this works, but for away it does not. Then I asked why, and you said you were talking about 1.x. However, Felipe was clearly talking about head ("considering the current status rewrite"). -Mark |
From: Luke S. <lsc...@us...> - 2005-02-08 00:41:41
|
I apparently confused several different emails in reading the entire thread at once. my statement most nearly relates to "Yes, every PRPL should define what "Block All" is." which I proceeded to compare to the 1.x handling of away. having the prpls define what "block all" is substantially the same as having them define what away is. both will yeild unintuitive results. as per my email about what exactly icq does allow, we currently appear to add someone to the invisible list when we "block" them over icq. my thought would be that I had added them to the "ignore" list by blocking them. thus I would tend to say that icq should not have a "block" at all, since it appears to have two types of block, a status block and a message block. I am very sorry for the confusion I caused by poor quoting and poor threading. luke |
From: Luke S. <lsc...@us...> - 2005-02-08 00:19:42
|
On Sun, Feb 06, 2005 at 03:36:15PM -0500, Mark Doliner wrote: > On Sun, 6 Feb 2005 15:10:09 -0500, Luke Schierer wrote > > On Sun, Feb 06, 2005 at 11:56:03AM -0500, Mark Doliner wrote: > > > On Sat, 5 Feb 2005 01:37:46 -0600, Felipe Contreras wrote > > I never said we should only have *a* privacy list. Also, I really don't think > ICQ lets you go "away" or "na" to a single person. You're going to have to > show me a screenshot of the Windows ICQ client preferences for this for me to > believe otherwise. A screenshot. you are setting a high bar, as I'm not sure what will take a screenshot on windows 98. I cannot install ICQ 5.x, the most recent version, but looking at 2003b, I right click on your user name on a fresh, never before used icq install. the second to last option is "User's Unique settings" it opens up a dialog with a mix of tabs and a list of things (much like gaim 1.x preferences, but not built into a tree, just a list). the tabs available change depending on what is selected in the list. the default, "General", has 4 tabs. "Accept" "message" "alert" and "status". Accept deals with popups, saving the history, and what ip address to use. "message" has a single checkbox. it has the following label: "Leave this user a personal message for when you are away". if selected, a textarea is ungrayed. "alert" has more options. by default, two of them are ungrayed. "Set specific alerts for this user" and "disable sounds". if "disable sounds" is unselected there is a button to set custom sounds just for that user. if "set specifici alerts for this user" is selected, you have a number of options including blinkyness, sound, popups, and floating stuff. it is kinda similar to a cross between our buddy pounces and guificiations. under "status" you have "online status" with 2 checkboxes "always invisible to this user" and "always visible to this user". then it has accept modes. "accept when I'm away" "accept when i'm n/a" so on. under "security and privacy" from the main menu, you have an "invisible" list, an "ignore list" a "words" list and a "permission level" on a side note, based on the fact that my ignore list is empty and my invisible list has 59 users, it appears our block is adding to the invisible list but nto the ignore list. is there a way to put someone on the ignore list from gaim? there shoudl be. I cannot find the option to always appear away that I recall using in the past, so I will withdraw that claim, it has apparently been removed from the clients. still, there IS an option to be either explicetly visible even when set to global invisible and one to be explicetly invisible even when otherwise visible. there are also 3 distinct lists (visible, invisible, and ignore), in addition to whatever that "words" list does. Hopefully you will accept the above verbose discription in place of the screenshot I do not know how to provide you. luke > > If Jabber DOES allow this, I'm still not sure that's reason enough to combine > status and privacy. It seems like a bad idea to me. > > -Mark |
From: Mark D. <ma...@ki...> - 2005-02-08 00:56:13
|
On Mon, 7 Feb 2005 19:19:36 -0500, Luke Schierer wrote > > I never said we should only have *a* privacy list. Also, I really don't think > > ICQ lets you go "away" or "na" to a single person. You're going to have to > > show me a screenshot of the Windows ICQ client preferences for this for me to > > believe otherwise. > > A screenshot. you are setting a high bar, as I'm not sure what will > take a screenshot on windows 98. I cannot install ICQ 5.x, the most > recent version, but looking at 2003b, I right click on your user > name on a fresh, never before used icq install. the second to last > option is "User's Unique settings" it opens up a dialog with a mix > of tabs and a list of things (much like gaim 1.x preferences, but > not built into a tree, just a list). the tabs available change > depending on what is selected in the list. the default, "General", > has 4 tabs. "Accept" "message" "alert" and "status". Accept deals > with popups, saving the history, and what ip address to use. > "message" has a single checkbox. it has the following label: "Leave > this user a personal message for when you are away". if selected, a > textarea is ungrayed. "alert" has more options. by default, two of > them are ungrayed. "Set specific alerts for this user" and "disable > sounds". if "disable sounds" is unselected there is a button to set > custom sounds just for that user. if "set specifici alerts for this > user" is selected, you have a number of options including blinkyness, > sound, popups, and floating stuff. it is kinda similar to a cross > between our buddy pounces and guificiations. under "status" you > have "online status" with 2 checkboxes "always invisible to this > user" and "always visible to this user". then it has accept modes. > "accept when I'm away" "accept when i'm n/a" so on. > > under "security and privacy" from the main menu, you have an > "invisible" list, an "ignore list" a "words" list and a "permission > level" on a side note, based on the fact that my ignore list is > empty and my invisible list has 59 users, it appears our block is > adding to the invisible list but nto the ignore list. is there a way > to put someone on the ignore list from gaim? there shoudl be. > > I cannot find the option to always appear away that I recall using > in the past, so I will withdraw that claim, it has apparently been > removed from the clients. still, there IS an option to be either > explicetly visible even when set to global invisible and one to be > explicetly invisible even when otherwise visible. there are also 3 > distinct lists (visible, invisible, and ignore), in addition to > whatever that "words" list does. > > Hopefully you will accept the above verbose discription in place of > the screenshot I do not know how to provide you. I'll accept it in that it means I'm right :-) The "invisible" list is the same as the "block" list in AIM, and the "visible" list is the same as the "allow" list. They merged the protocols, remember? For both AIM and ICQ, if your permit/deny setting is "allow only the users below" then your invisible/block list is ignored, and your visible/allow list is activated. If your permit/deny setting is "block only the users below" then the opposite is true--your invisible/block list is activated and your visible/allow list is ignored. You may be wondering how you set your permit/deny setting in ICQ. Being "invisible" is equivalent to setting your permit/deny setting to "allow only the users below." Being anything other than invisible is equivalent to setting your permit/deny setting to "block only the users below." ICQ has two tiers of blocking: appear-as-invisible and ignore-all-messages. Ignore-all-messages has the same affect as the AIM block list. While with appear-as-invisible you can still receive messages from the person. I think "accept when I'm away" and "accept when i'm n/a" are handled client-side. I think it just affects whether the message will make a sound or make ICQ blink or whether the message will popup. -Mark |
From: Mark D. <ma...@ki...> - 2005-02-08 01:52:59
|
On Mon, 7 Feb 2005 19:19:36 -0500, Luke Schierer wrote > "message" has a single checkbox. it has the following label: "Leave > this user a personal message for when you are away". if selected, a I talked to Luke and he pointed out that I wasn't reading his email closely enough. I looked at this option and it basically just sets a different auto-reply for the user. It does not change the away message the user sees when he "get info"'s your away message. I don't even remember what we were talking about, but I thought someone might be interested. -Mark |
From: Tim R. <tim...@co...> - 2005-02-06 21:06:03
|
Felipe Contreras wrote: > 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. An entire rewrite wouldn't be needed just to add a gaim_privacy_is_blocked() function. > 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.. Why not? The way I see it, you could either have a bunch of lists (permit, deny, invisible to, visible to, etc), or a single list consisting of a { "uniqueized buddy list" + "all nonbuddies that have some setting set for them" }. That is, you can either have a bunch of lists of screennames, or a single list of screennames, and a bunch of settings associated with each member of the list. I'm not sure which way is better. I feel you haven't justified your assertion that your single-list-of-buddies-each-with-associated-attributes is better than multiple lists. --Tim |
From: Felipe C. <fel...@gm...> - 2005-02-06 22:06:03
|
On Sun, 06 Feb 2005 15:05:50 -0600, Tim Ringenbach <tim...@co...> wrote: > Felipe Contreras wrote: > > 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. > > An entire rewrite wouldn't be needed just to add a > gaim_privacy_is_blocked() function. Of course not, in fact I alredy implemented it a while ago. The problem is that it's 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.. > > Why not? The way I see it, you could either have a bunch of lists > (permit, deny, invisible to, visible to, etc), or a single list > consisting of a { "uniqueized buddy list" + "all nonbuddies that have > some setting set for them" }. That is, you can either have a bunch of > lists of screennames, or a single list of screennames, and a bunch of > settings associated with each member of the list. > > I'm not sure which way is better. I feel you haven't justified your > assertion that your > single-list-of-buddies-each-with-associated-attributes is better than > multiple lists. Of course, but what I'm about is the API, both implementations can share the same API. Probably if you don't have many permitted/denied buddies lists are much better. And in the current code it may be even more efficient to have multiple lists. I think a single list is better because I've always thought a single GaimDude list would be very helpful. For example, a GaimBuddy may have a GaimDude assotiated, that way, each time you want to generate the tooltip, or the menu entry, you'll not have to search any list. PRPLs implemented like the MSN prpl would also beneffict from it maybe storing GaimDude it it's internal account/screenname structures. Not to mention caching of the buddyicon pixmaps, having a single place to store information like buddy alias, that is currently duplicated along all the buddies, one for each group. Also it will easy the buddy updating proccess. Right now each time we get something as serv_got_alias we have to search the entire buddy list to retrieve those account/screenname things. That is tedious and error prone, there are still some places where we don't update all the buddies properly. Seriously, go to blist.c:gaim_find_buddies, and add a printf inside the for to see how many times gaim_find_buddies is called. GaimPresence (for buddies) is basically the same thing, an account/screenname structure that has a group of GaimBuddies. I think having a single GaimDude will bring many advantages, right now I'm using that for privacy, and surely can be used for status, but it's the possibilities what I'm after. Anyway, for now, I want to purpose the API. It can be re-implemented in lists later. -- Felipe Contreras |
From: Tim R. <tim...@co...> - 2005-02-06 23:30:51
|
Felipe Contreras wrote: > On Sun, 06 Feb 2005 15:05:50 -0600, Tim Ringenbach > <tim...@co...> wrote: >>I'm not sure which way is better. I feel you haven't justified your >>assertion that your >>single-list-of-buddies-each-with-associated-attributes is better than >>multiple lists. > > > Of course, but what I'm about is the API, both implementations can > share the same API. I thought I was talking about the API though. Are we going to have gaim_privacy_list_add(account, "somelist" (e.g. deny), screenname); or gaim_dude_privatey_setting_set(dude, "somesetting" (e.g. blocked), TRUE); I wasn't trying to say one way was better than the other in my previous email, rather I was trying to prod you into fully justifying your design. > Also it will easy the buddy updating proccess. Right now each time we > get something as serv_got_alias we have to search the entire buddy > list to retrieve those account/screenname things. That is tedious and > error prone, there are still some places where we don't update all the > buddies properly. > > Seriously, go to blist.c:gaim_find_buddies, and add a printf inside > the for to see how many times gaim_find_buddies is called. > > GaimPresence (for buddies) is basically the same thing, an > account/screenname structure that has a group of GaimBuddies. > > I think having a single GaimDude will bring many advantages, right now > I'm using that for privacy, and surely can be used for status, but > it's the possibilities what I'm after. I do agree that, there are more than a few things that GaimBuddy is used for, that it shouldn't be used for, because GaimBuddy's are not unique for a given screenname on a given account. If a buddy is in more than one group, it has more than one GaimBuddy. I almost wonder if we shouldn't rename GaimBuddy to GaimBlistnodeBuddy, to remind people it's a blist node. I haven't looked at the code enough, but I'm told GaimPresense tries to be the unique account/screenname thingy, at least for statuses. I'm not sure how good of a job it does. Maybe GaimBuddy should be renamed GaimBlistnodeBuddy, and a GaimblnBuddy has a pointer to a GaimBuddy, where a GaimBuddy has everything that is always the same between two instances of the same buddy on the same account on the buddy list, and can also exist for buddies not on the list at all. The new GaimBuddy might have a GaimPresense member, amoung others, I don't know. --Tim |
From: Felipe C. <fel...@gm...> - 2005-02-07 02:18:08
|
On Sun, 06 Feb 2005 17:30:40 -0600, Tim Ringenbach <tim...@co...> wrote: > Felipe Contreras wrote: > > On Sun, 06 Feb 2005 15:05:50 -0600, Tim Ringenbach > > <tim...@co...> wrote: > >>I'm not sure which way is better. I feel you haven't justified your > >>assertion that your > >>single-list-of-buddies-each-with-associated-attributes is better than > >>multiple lists. > > > > > > Of course, but what I'm about is the API, both implementations can > > share the same API. > > I thought I was talking about the API though. Are we going to have > gaim_privacy_list_add(account, "somelist" (e.g. deny), screenname); or > gaim_dude_privatey_setting_set(dude, "somesetting" (e.g. blocked), TRUE); > > I wasn't trying to say one way was better than the other in my previous > email, rather I was trying to prod you into fully justifying your design. Well, since a dude is an account/screenname, I was thinking on two posibilities: a) gaim_dude_set_mode(dude, "mode", TRUE); or b) gaim_dude_set_mode(account, screenname, "mode", TRUE); Obviously the first one would be efficient when passing along GaimDude objects, and linking them with GaimBuddies, and such. The second one would be more efficient if we don't pass along objects, and will use lists in order to store the modes. > > Also it will easy the buddy updating proccess. Right now each time we > > get something as serv_got_alias we have to search the entire buddy > > list to retrieve those account/screenname things. That is tedious and > > error prone, there are still some places where we don't update all the > > buddies properly. > > > > Seriously, go to blist.c:gaim_find_buddies, and add a printf inside > > the for to see how many times gaim_find_buddies is called. > > > > GaimPresence (for buddies) is basically the same thing, an > > account/screenname structure that has a group of GaimBuddies. > > > > I think having a single GaimDude will bring many advantages, right now > > I'm using that for privacy, and surely can be used for status, but > > it's the possibilities what I'm after. > > I do agree that, there are more than a few things that GaimBuddy is used > for, that it shouldn't be used for, because GaimBuddy's are not unique > for a given screenname on a given account. If a buddy is in more than > one group, it has more than one GaimBuddy. I almost wonder if we > shouldn't rename GaimBuddy to GaimBlistnodeBuddy, to remind people it's > a blist node. > > I haven't looked at the code enough, but I'm told GaimPresense tries to > be the unique account/screenname thingy, at least for statuses. > > I'm not sure how good of a job it does. Maybe GaimBuddy should be > renamed GaimBlistnodeBuddy, and a GaimblnBuddy has a pointer to a > GaimBuddy, where a GaimBuddy has everything that is always the same > between two instances of the same buddy on the same account on the buddy > list, and can also exist for buddies not on the list at all. The new > GaimBuddy might have a GaimPresense member, amoung others, I don't know. Yes, when I first looked at it I thought GaimBuddy, was in fact a GaimDude. So I also think GaimBuddy should be reanamed to GaimBuddyInstance, or something, and make GaimBuddy what I call GaimDude. I never liked the GaimBuddy approach, but faceprint doesn't share my opinion. So I coded GaimDude. -- Felipe Contreras |
From: Richard L. <rl...@wi...> - 2005-02-07 02:27:08
|
On Sun, 2005-02-06 at 20:18 -0600, Felipe Contreras wrote: > Well, since a dude is an account/screenname, I was thinking on two posibi= lities: > a) gaim_dude_set_mode(dude, "mode", TRUE); or > b) gaim_dude_set_mode(account, screenname, "mode", TRUE); I'm still trying to wrap my head around this whole "dude" business... If GaimDude =3D (account, screenname), then GaimDude is a subset of GaimBuddy. What's your rationale for creating a new type? Is it because the [set of GaimDudes] is a superset of the [set of GaimBuddies] -- in other words, the privacy API would be working with (account, screenname) combinations that are not on the buddy list? Richard |
From: Felipe C. <fel...@gm...> - 2005-02-07 03:16:32
|
On Sun, 06 Feb 2005 20:26:58 -0600, Richard Laager <rl...@wi...> wrote: > On Sun, 2005-02-06 at 20:18 -0600, Felipe Contreras wrote: > > Well, since a dude is an account/screenname, I was thinking on two posibilities: > > a) gaim_dude_set_mode(dude, "mode", TRUE); or > > b) gaim_dude_set_mode(account, screenname, "mode", TRUE); > > I'm still trying to wrap my head around this whole "dude" business... > > If GaimDude = (account, screenname), then GaimDude is a subset of > GaimBuddy. What's your rationale for creating a new type? Is it because > the [set of GaimDudes] is a superset of the [set of GaimBuddies] -- in > other words, the privacy API would be working with (account, screenname) > combinations that are not on the buddy list? Let's suppose you a buddy with screenname "x", in some account, and you have it in "work", "linux", and "friends" groups. You'll have 3 GaimBuddy structures, one for each group. If you are going to save some data, like the per-buddy privacy setting, or the alias for that buddy, will it be different for each GaimBuddy structure? No, it won't, hence the need of a proper structure to store such account/screenname data. And of course, there is people that ain't in your buddy list. -- Felipe Contreras |
From: Luke S. <lsc...@us...> - 2005-02-07 16:17:46
|
On Sun, Feb 06, 2005 at 08:26:58PM -0600, Richard Laager wrote: > On Sun, 2005-02-06 at 20:18 -0600, Felipe Contreras wrote: > I'm still trying to wrap my head around this whole "dude" business... > > If GaimDude = (account, screenname), then GaimDude is a subset of > GaimBuddy. What's your rationale for creating a new type? Is it because > the [set of GaimDudes] is a superset of the [set of GaimBuddies] -- in > other words, the privacy API would be working with (account, screenname) > combinations that are not on the buddy list? Correct, you frequently block people who are not on your buddy list. Dealing with authorization on jabber, yahoo, and msn, as part of privacy, you maintain some awareness of people who may or may not be on your buddy list in this manner also. Currently in Jabber, there are people on my buddy list who show only as offline, because they are subscribed to my presence, but I am not subscribed to theirs, or at least that is how it seems, since I do not remember many of the screennames showing up with the "broken" lightbulb we use for such things. I think that this is not an ideal way of handling this, that some other interface would be more intuitive than using a GaimBuddy for it, hence another struct to contain information related to privacy about people who may or may not be on your buddy list. Given Jabber's "temporarily hide from" and the similar ability in ICQ that I have used and Mark would like me to prove still exists, I proposed, and shx agreed and acted on an approach that merges status and privacy. Mark (seems) to either object strongly to this approach. Tim seems to object primarily to a single list implementation of it, which I am not significantly concerned about (it could be done with a number of lists, and keeping status and privacy separate, or it could be done with a single list and reading the list into a hash table using account screenname pairs as the key, or it could be done with a single list, using pointers from the GaimBuddy to the new struct to circumvent searching the list where possible). luke > > Richard > |
From: Peter L. <spa...@si...> - 2005-02-07 00:05:41
Attachments:
spam_spam_spam_and_spam.vcf
|
Tim Ringenbach wrote: > Felipe Contreras wrote: > >> 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. > > > An entire rewrite wouldn't be needed just to add a > gaim_privacy_is_blocked() function. > At your urging, Tim, I've been having a ponder upon all this privacy stuff. And here's my 'eventual' conclusion. Whilst not an easy solution, nor have I fully fleshed it out, to my mind it has some benefits. But I thought I'd throw it into the pile. I've got medical appointments lined up for the next few days, and I don't expect my eyesight to be good enough to be able to write, so i thought I'd get this out sooner, rather than later. Whilst messing around with some font preferences yesterday, it occurred to me that I can't have independent font rendering on a per account setting. I then extended this thought to how I'd personally like to have some plugins work with some accounts, and not with others. And it wasn't far from that thought, and with a nod to my cyberstalker, that I noted how difficult it is to import an ignore list when changing/creating new accounts. Not only that, a change of my buddy icon involves editing too many accounts to be considered 'easy'. It then struck me how single-signon centric gaim really is. Sure, it supports multiple accounts for logins, but apart from that, I can't really think of much immediate functionality that inspires multiple account usage, beyond the 1.x status implementation. So my thoughts moved to thinking of an identity, which could contain multiple accounts. Or multiple identities for a single account (I guess like what Yahoo does with their multiple profiles, but I've never used that function so I can't say for sure). Why do I think this would this be an advantage? For starters, preferences (such as font rendering) could become available on a per-identity basis. Auto-Away could become different for identities allowing a set of personal auto-aways for your home identity, and a work away (with an eye to my colourful language). OK, so that's the vague idea. How does this relate to privacy? Not much, I guess. Unless one starts to think of how privacy really isn't a per-account thing, but something that should be enforcable system wide, but can glean info from an account. At the moment, the problem to me appears to be that privacy is account centric, and is affecting status to some degree due to some protocols 'using' status as a form of privacy (eg, Yahoo presence). Privacy cannot be enforced on a per-protocol level. Nor is it easily possible to 'check' what the local permit/deny list is without having to log the account in, or open up the .xml file. Nor can one easily import a block list from one account to another (sounds crazy, but if you have a couple of AIM accounts, and want to use the same block list, or if you've managed to get one account completely unworkable but still have a loacl block list, one may want to import to the 'new' account). One could now think of there now being global preferences, identity preferences and account preferences. Identity could import settings from the global settings, or from an account. Status would become neither global nor specifically tied to an account. And privacy would be seperated out from a per-account basis in so far as ignore lists, and conceptually at least might be easier to think of 'ignore Bleeter on accounts (a) (b) and (c) but let them pass IM's on (d) and chat invites on (e)', as that's an identity setting, and not a global thing. Further, this would stop gaim from being dependant on what the developers *think* should be held in an account subsystem, merely because 'it's what the current protocol set' allows, which to my way of thinking is the cause of the grief to start with. So while this whole gaim_identity is not quite where you urged me to have a think and a ponder on, it's where I ended up because gaim doesn't actually have it. And gaim still is stuck in a mindset of all other IM clients that I've seen, as opposed to being a complete messenging solution. As I said, I haven't really thought this through thoroughly, but I thought I'd throw it in to the pile. Apologies for the vagueness and randomness (see closing remark). I urge you to have a think about this, and not merely immediately dismiss it as it is a pointless proposal for changing the paradigm in which gaim currently operates, and the amount of work it'd no doubt involve. I'm off to the eye quacks again in a couple of hours time, so probably won't be up to replying for at least 48 hours. </end_caffeine_induced_beard_stroking_causing_random_contemplations> |
From: Ethan B. <ebl...@cs...> - 2005-02-07 03:20:59
|
Peter Lawler spake unto us the following wisdom: [snip] > It then struck me how single-signon centric gaim really is. Sure, it=20 > supports multiple accounts for logins, but apart from that, I can't=20 > really think of much immediate functionality that inspires multiple=20 > account usage, beyond the 1.x status implementation. So my thoughts=20 > moved to thinking of an identity, which could contain multiple accounts.= =20 > Or multiple identities for a single account (I guess like what Yahoo=20 > does with their multiple profiles, but I've never used that function so= =20 > I can't say for sure). While I agree with most of the conclusions that you drew from this per- spective, I think that it is a perspective that runs contrary to my view of how gaim works. If you look at gaim as a collection of independent accounts, then all of the things you discussed become issues that gaim does not handle well; however, if you view gaim as a program which attempts to integrate all of those accounts such that you can pretend day in and day out that you have only _one_ account on which all of those diverse buddies are accessible, then those conclusions don't fol- low. My personal view of gaim is closer to the latter -- I want it to behave like I have a single giant account in every respect which does not force me to know otherwise (e.g., adding buddies, signing on, etc.). Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Luke S. <lsc...@us...> - 2005-02-07 14:37:57
|
On Sun, Feb 06, 2005 at 10:20:51PM -0500, Ethan Blanton wrote: > While I agree with most of the conclusions that you drew from this per- > spective, I think that it is a perspective that runs contrary to my view > of how gaim works. If you look at gaim as a collection of independent > accounts, then all of the things you discussed become issues that gaim > does not handle well; however, if you view gaim as a program which > attempts to integrate all of those accounts such that you can pretend > day in and day out that you have only _one_ account on which all of > those diverse buddies are accessible, then those conclusions don't fol- > low. My personal view of gaim is closer to the latter -- I want it to > behave like I have a single giant account in every respect which does > not force me to know otherwise (e.g., adding buddies, signing on, etc.). > > Ethan This is more or less my view also, with the exception that I want to be able to get at the capabilities that not all protocols offer. I think Gaim should continue to assume that a single instance of the program represents a single identity, and let multiple identities be handled with the -c option. luke > > -- > The laws that forbid the carrying of arms are laws [that have no remedy > for evils]. They disarm only those who are neither inclined nor > determined to commit crimes. > -- Cesare Beccaria, "On Crimes and Punishments", 1764 |