(Sorry for being so sluggish with responses, it takes time to get back into the programming mindframe for this project, hopefully it will get better :)
Ok, "edit" sounds like a good name, and I see now that it may be more easy for the programmer to edit watch and trust edges separately. The current implementation came from being too lazy to change my client too much, so it continues to use only one variable to determine the relationship :) but I agree that editwatch and edittrust are more intuitive.
editfriendsgroups accepted a struct of friend ids to its groupmasks key ...
Actually, my structure of request was copied from the LJ method editfriends, because I think groupmasks do not belong to editfriendgroups - if this function is called "edit friend groups", it should do just that, and not *also* optionally edit the user's circle. This is the way I had used it in my client anyway, don't know if the other LJ clients use editfriendgroups instead of editfriends as they're supposed to, but I think there are too many changes to talk of backward compatibility, so it's preferrable to do it logically on our end.
why does providing a groupmask to editcircle's add key mean that you can't simultaneously change the user's watch edge?
I guess it was the same consideration - editing group relationship is "different" from editing user relationship, so they're not supposed to be used together. But it's no problem to include both of these keywords.
switching all back-end terms to front-end terms instead.
It's also that "trust" and "watch" are shorter than "access" and "subscription", both are even the same length - so they sound a bit better in my mind :) But it's no problem to change, so the developers don't have to learn two sets of terms.
I kind of find editcircle a bit overloaded.
It was made symmetrical to "getcircle", because when the client includes the circle management functionality, I believe it makes more sense to get all the available data right away because it's all necessary - so it may just as well be done in one request rather than calling at least 3 functions one after another (trust groups, content filters and watched/trusted users). But then, the client would not edit all of them simultaneously, so splitting the edit part into at least 3 functions also makes sense, but then they're not symmetrical? I can't decide what's better :)
and thanks again!! *goes to think of the rest of the comments about content filters...*
no subject
Ok, "edit" sounds like a good name, and I see now that it may be more easy for the programmer to edit watch and trust edges separately. The current implementation came from being too lazy to change my client too much, so it continues to use only one variable to determine the relationship :) but I agree that editwatch and edittrust are more intuitive.
editfriendsgroups accepted a struct of friend ids to its groupmasks key ...
Actually, my structure of request was copied from the LJ method editfriends, because I think groupmasks do not belong to editfriendgroups - if this function is called "edit friend groups", it should do just that, and not *also* optionally edit the user's circle. This is the way I had used it in my client anyway, don't know if the other LJ clients use editfriendgroups instead of editfriends as they're supposed to, but I think there are too many changes to talk of backward compatibility, so it's preferrable to do it logically on our end.
why does providing a groupmask to editcircle's add key mean that you can't simultaneously change the user's watch edge?
I guess it was the same consideration - editing group relationship is "different" from editing user relationship, so they're not supposed to be used together. But it's no problem to include both of these keywords.
switching all back-end terms to front-end terms instead.
It's also that "trust" and "watch" are shorter than "access" and "subscription", both are even the same length - so they sound a bit better in my mind :) But it's no problem to change, so the developers don't have to learn two sets of terms.
I kind of find editcircle a bit overloaded.
It was made symmetrical to "getcircle", because when the client includes the circle management functionality, I believe it makes more sense to get all the available data right away because it's all necessary - so it may just as well be done in one request rather than calling at least 3 functions one after another (trust groups, content filters and watched/trusted users). But then, the client would not edit all of them simultaneously, so splitting the edit part into at least 3 functions also makes sense, but then they're not symmetrical? I can't decide what's better :)
and thanks again!! *goes to think of the rest of the comments about content filters...*