Protocol optimization: frgrp_N_public in login mode
Short, concise description of the idea
A simple extension to the login mode of the client-server protocol may save resources for the server and make life a little easier for the client developers.
Full description of the idea
As an optimization, the login protocol mode already sends frgrp_N_name and frgrp_N_sortorder information to the client. These fields are also available from the getfriendgroups mode, but somebody thought the client may as well have them on login even without asking.
This is a good idea, and can be completed by sending frgrp_N_public at the same time, too.
An ordered list of benefits
Almost zero CPU cost to the server, becase the is_public field is already part of the SELECT done to fetch the other fields.
Very little bandwidth cost, because there are at most thirty public groups to report (often much less)
Actually saves bandwidth and another database hit by eliminating a superfluous additional protocol request to getfriendgroups
Makes much more sense to the client developer who wishes to create a UI for friends groups, and who needs this information anyway.
An ordered list of problems/issues involved
This should have no adverse effects on existing clients; they will have the option of still calling getfriendgroups when they like.
One day, getfriendgroups might be deprecated, but there's no pressing need to do that (it might be useful to keep around for a client refresh that doesn't require logging out and in again).
An organized list, or a few short paragraphs detailing suggestions for implementation
This requires a small change to ljprotocol.pl