i've done some checking and as per the source code of the message send page of myplace, the messages title is limited to 50 chars, the message body is limited to 60 cols * 15 rows = 900 chars are these fixed table values or is just a limit imposed by exp on that specific page?API Definition wrote:292 NOTIFYGET
{int4 id}|{int4 from_user_id}|{str from_user_name}|{int4 date}|{int4 type}|{str title}|{str body}
(i'm asking because fixed values is way better for me than the up to 5000 bytes of the string definition.)
In this context, if count is "count is the number of events pending for this anime " why should't it be a int4 ?API Definition wrote:293 NOTIFYGET
{int4 aid}|{int4 type}|{str count}|{int4 date}|{str anime_name}
Can someone give an example of a api 293 code, i don't have any pending anime notifies, and would like to know of the possible values of the count thing.
Does the db imposes any kind of char limit to anime titles?
By the way, when checking webaom's latest version (117), i've noticed the use of two extra args in the auth, enc=utf8, and comp=1 and then checked the udp api dev wiki page for info on those, and that arose more questions:
1) as for compression, the api would only use it for replys longer than possibly 1460 bytes, but is the client also able to send compressed commands (i can see some commands where it would be nice to have compression, also for narrow band users it would be nice to have compression support as their udp packets without fragmentation are realy small) and if the client is able to send compressed data, how would we flag it to the api?
1a) couldn't we add some kind of mtu arg to the auth command, example: i'm a modem user, and i got a 576 MTU (less UDP and IP headers), and the API sends 1500 bytes (less UDP and IP headers) packets, i can lose half of API packet, but if the API could compress the packets if they were bigger than the client mtu, we could prevent some packet loss, and following error correction by the client .
2) as for encoding, if one does not pass the enc= arg in the auth command, the api defaults to ascii, right?
2a) also i would give a 202/203 reply code on enconding set to default (203 if client outdated), if encoding requested was not supported, if supported, return the default 200/201.
3) as for the ENCRYPT command, it makes sense only to encrypt the auth command, because of the password, other than that, i don't see any motive to use encryption on the other commands, and why create a new password just for encrypt, use for the md5 string a concat of username+password+salt, that should solve issues without any more fields.
3a) and if the only use of the ENCRYPT command was to pass the auth command without a clear text password, wouldn't it make more sense to set as default password as a MD5 string instead of the clear text version?
Couldn't we extend the NOTIFY command to include buddy support?
That way if we requested a notify command and number_of_online_buddys was more than 0 we could then do a BUDDYLIST to get the status of the users.API Definition wrote:NOTIFY: Notifications
Command String:
NOTIFY
Possible Replies:
290 NOTIFICATION
{int4 pending_notifies}|{int4 pending_msgs}|{int4 number_of_online_buddys}
501 LOGIN FIRST
(this as just to save 2 packets, as i do a notify to check for messages)
About the flood protection policy, i've been doing something like this, i use short term policy for the first 5 packets then switch for the long term, my question is, can we use short term for 5 packets, then change for long term for 30 seconds, then use short term again for another 5 packets then change again, and so on, or it's short for the first 5 packets and then every other packet sent is long term?
Sorry for the long list, but i do have some questions
[edited some times to improve readabilty ]