On Sun, 6 Feb 2005 15:32:23 -0500, Mark Doliner <mark@...> 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
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:
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:
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
"visible" -> _("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.