I apparently don't even remember enough about Perl to actually understand the code I'm reading, so please, take all the time you need to get back into the mindset! I kind of sprung this on you all of a sudden, many months after you'd last given it any thought.
I think groupmasks do not belong to editfriendgroups
That's a fair point! I'd been thinking of editfriendsgroups as an edit not just of the name/sorting/etc of the group, but also of who is in the group, so the combination of functionality seemed justified to me, but I can also see your point about keeping them separate. Also, I like the idea of not duplicating functionality all over the place -- if you can edit a user's trustmask with editcircle, then LJ-compatibility alone is not a good enough reason to support that same functionality in a second method using a different request structure.
...editing group relationship is "different" from editing user relationship, so they're not supposed to be used together.
Oh! Interesting take on it. I'm used to thinking of all those things as going together, since on DW itself when you want to edit your relationship to a single user from the manage/circle/add page, you can change their watch status, trust status, trust groups and content filters all in one step.
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.
Bleh, I don't feel qualified to decide. I think if we're getting rid of "edge", most of my issues with the back end terms vanish, since watch and trust are pretty intuitively mapped to the front-end terms. Content filters is a bigger leap, but not an impossible one.
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 :)
Yeah, see, I waffled a lot over that part! But then I decided to just go ahead and talk it out with you, because then at least we'll have thought it through from all the angles. Mostly when I was considering writing out the documentation for it I just sat back blinking and thought, wow, that is a lot for one method to do! This page is going to be huge! And have a lot of statements like, "If you set the such and such key, and then if something is changed like so, or something is created, then the return structure will possibly contain the following keys..."
Astonishingly, the lack of symmetry doesn't bother me so much here -- I know! How can that be, when I am all about symmetry everywhere else? But I figure if you add in a quick getcontentfilters method to mirror the gettrustgroups one, then having editcircle, edittrustgroups and editcontentfilters seems quite natural, and it becomes quite clear that the ability to get filters using getcircle is provided simply for convenience.
I am torn, though, between wanting simpler edit methods that have straightforward return structs, and wanting a way to, if the client developer desired, do a bunch of circle editing stuff all in one call, like create a trust group and add some users to it. Since I think a case can be made for both sides, we should just leave it as is. No point changing something if the change does not have a clear advantage over the existing code. The documenter will just have to suck it up and explain how all the different keys affect the possible return structures! :)
Also, more on content filters now that I've actually made one (before, they were sort of... theoretical to me). Why does the includecontentfilters key of getcircle only return the names of the users in the filters, and not any of the other data that might be associated to each user, like the tags or ratings to further filter their entries by? Was that a deliberate omission?
If you left the other stuff out for the purpose of keeping things simple right now but with plans to add expanded content filters support later, then maybe it would be better to leave content filters out entirely right now? That way client apps won't start using a method that's still in flux. Given the way the users in a filter are currently returned as a space-separated string, adding in the extra info will probably require a change to that, and that's the kind of API modification that has an impact on client apps.
no subject
That's a fair point! I'd been thinking of editfriendsgroups as an edit not just of the name/sorting/etc of the group, but also of who is in the group, so the combination of functionality seemed justified to me, but I can also see your point about keeping them separate. Also, I like the idea of not duplicating functionality all over the place -- if you can edit a user's trustmask with editcircle, then LJ-compatibility alone is not a good enough reason to support that same functionality in a second method using a different request structure.
Oh! Interesting take on it. I'm used to thinking of all those things as going together, since on DW itself when you want to edit your relationship to a single user from the manage/circle/add page, you can change their watch status, trust status, trust groups and content filters all in one step.
Bleh, I don't feel qualified to decide. I think if we're getting rid of "edge", most of my issues with the back end terms vanish, since watch and trust are pretty intuitively mapped to the front-end terms. Content filters is a bigger leap, but not an impossible one.
Yeah, see, I waffled a lot over that part! But then I decided to just go ahead and talk it out with you, because then at least we'll have thought it through from all the angles. Mostly when I was considering writing out the documentation for it I just sat back blinking and thought, wow, that is a lot for one method to do! This page is going to be huge! And have a lot of statements like, "If you set the such and such key, and then if something is changed like so, or something is created, then the return structure will possibly contain the following keys..."
Astonishingly, the lack of symmetry doesn't bother me so much here -- I know! How can that be, when I am all about symmetry everywhere else? But I figure if you add in a quick getcontentfilters method to mirror the gettrustgroups one, then having editcircle, edittrustgroups and editcontentfilters seems quite natural, and it becomes quite clear that the ability to get filters using getcircle is provided simply for convenience.
I am torn, though, between wanting simpler edit methods that have straightforward return structs, and wanting a way to, if the client developer desired, do a bunch of circle editing stuff all in one call, like create a trust group and add some users to it. Since I think a case can be made for both sides, we should just leave it as is. No point changing something if the change does not have a clear advantage over the existing code. The documenter will just have to suck it up and explain how all the different keys affect the possible return structures! :)
Also, more on content filters now that I've actually made one (before, they were sort of... theoretical to me). Why does the includecontentfilters key of getcircle only return the names of the users in the filters, and not any of the other data that might be associated to each user, like the tags or ratings to further filter their entries by? Was that a deliberate omission?
If you left the other stuff out for the purpose of keeping things simple right now but with plans to add expanded content filters support later, then maybe it would be better to leave content filters out entirely right now? That way client apps won't start using a method that's still in flux. Given the way the users in a filter are currently returned as a space-separated string, adding in the extra info will probably require a change to that, and that's the kind of API modification that has an impact on client apps.