[Pidgin] #10005: no API to change your own nickname

[Pidgin]

#10005: no API to change your own nickname
-------------------------+--------------------------------------------------
 Reporter:  yelo3        |        Owner:           
     Type:  enhancement  |       Status:  closed   
Milestone:  2.7.0        |    Component:  libpurple
  Version:  2.6.1        |   Resolution:  fixed    
 Keywords:               |  
-------------------------+--------------------------------------------------

Comment(by felipec):

 Replying to [comment:3 darkrain42]:
 > No, actually.  This bug was filed *before* your suggestion by several
 months.

 No what? I didn't imply my suggestion was before this bug.

 I only said: it's already fixed.

 If you are at all familiar with other bug systems, like the infamous
 bugzilla, you would know that there's a resolution called ALREADYFIXED
 that would apply tho this bug.

 And in any case, I've suggested this API since way before you even joined
 the project.

 > The API is also much more capable of asynchronicity than your proposed
 API.

 Perhaps, but it was clearly based on my proposal. Other projects with good
 attribution practices would have in the commit message:
 "Based on the suggestion by Felipe Contreras."

 At the very least a comment on the mailing list, with me CC'ed, would be
 pertinent, as I'm clearly one of the persons that know about this problem.
 Not to mention that you didn't contact other users.

 Also, it goes against the already established APIs that clients are
 already using, like serv_alias_buddy(), and
 msn_act_id()/msn_set_friendly_name().

 I'm glad you finally realize that operations that go through the network
 should be asynchronous; I suggested that many years ago (before you
 joined). But in the meantime most operations are synchronous (like
 serv_alias_buddy), so I don't see that as a reason to reject a patch.

 Also, it's messing up the layers: purple_account_set_public_alias() is not
 really doing anything with the account; it's doing basically
 serv_set_alias(), but then the prpl would eventually call
 purple_connection_set_display_name(). Agreed the connection should not
 have a display_name, so it's already all messed up, but serv_set_alias()
 would be clearer.

 And finally, pretty much everyone knows that callbacks should have a
 pointer for user data; you never know what the client would need there.

 But it's understandable that you got it wrong, since the API is not even
 used by Pidgin, and no discussion happened on the mailing list.

 Imagine, if you can, a client that as an object for asynchronous
 operations, like GAsyncResult. Such client would pretty much *need* to
 know which async object triggered the success/failure callback, but from
 the callback it would not be possible to know that. So what does the
 client do? It will have to assume that the operation succeeded right after
 calling purple_account_set_public_alias(), so the asynchronous callbacks
 are useless. But not only that; nobody is checking if the asynchronous
 callbacks are NULL; which again, everyone knows callbacks might be, so the
 client would have to provide dummy callbacks even though it cannot do
 anything with the result.

 So, congratulations on making the API *look* fancier with your patch; it's
 not achieving anything without user_data.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/10005#comment:4>
Pidgin <http://pidgin.im>
Pidgin