Lobbydev meeting minutes 2012-03-11

Lobbydev meeting minutes 2012-03-11

Archive of lobby developer discussions

Moderators: Moderators, Lobby Developers

Post Reply
User avatar
Lobby Developer
Posts: 69
Joined: 31 Dec 2011, 16:42

Lobbydev meeting minutes 2012-03-11

Post by cheapsheep » 14 Mar 2012, 23:54

Date: 11-3-2012
Present: [V]sheep, [CN]Zydox, _koshi_, a1983, [ARP]hoijui_irc, [PinK]halcyon, danil_kalina, aegis

=== Someone is volunteered for minutes ===

<_koshi_>someone volunteers for minutes
<_koshi_>good, thanks

=== Bot owners database / associate mail address with account for lost password ===

<_koshi_>i'll start with my point since [ARP]hoijui_irc is still eating
<_koshi_>build a database of bot owners, add a way to query it (push back if koshi's still eating)
<_koshi_>basically I'd like a way to determine who is responsible for any bot
<_koshi_>meaning user with botflag set
<aegis>my gf is gone all this next week
<aegis>if I made a big push to get server moved and setup with sql
<aegis>we could put it in the sql layer on the server and require it when assigning bot mode
<[V]sheep>would you associate bot with owner's accountID, mail or what ?
<aegis>any or all of the above
<_koshi_>preferrably email
<[ARP]hoijui_irc>yeah.. something more then just lobby name would be good
<aegis>we can add email to account registrations
<[ARP]hoijui_irc>no way to request that info only for bot owners?
<aegis>well, it'd simplify password handling
<aegis>like battle.net does for warcraft 3
<[V]sheep>yes that why i was asking... i believe mail would be nice for the score of ppl who "loose" their password :)
<aegis>you can optionally enter email when you register
<aegis>it's not required, but it's better than not
<aegis>then we can have both "easy to setup" accounts, and "verified email" accounts which get a few perks
<aegis>like password resets.
<a1983>Can user add later/change email?
<[ARP]hoijui_irc>ahh yeah that sounds ok
<aegis>would be feasible
<a1983> so conclusion?
<[V]sheep>we can 1) add optional email param to REGISTER cmd 2) add command to change email
<_koshi_>either way, I'd like email to be non-optional for bot owners. simply so we can ensure to be able to get a hold of them when their bots misbehave
<aegis>I can enforce in server
<aegis>"can't set bot mode unless user specifies email"
<danil_kalina>why bot. we must make it for all users
<aegis>so they say "can I have bot flag?" and mod says "you need to add an email address to your account"
<_koshi_>isn't the 'setting bot' sth an admin needs to do anyways?
<[V]sheep>then mail processing/validation is left as an exercice to the server implementor
<aegis>right, but mod can make mistake :P
<aegis>and probably a third command "password reset"
<[ARP]hoijui_irc>in other words.. mod does not have to check manually anymore
<aegis>command would tell them if user didn't have
<aegis>then they could just press up and run command again once user did
<aegis>easy way to do passwords resets if server doesn't have web-accessible UI but can send emails
<aegis>just send a temp password
<aegis>one-time pass, token, whatever
<a1983>Who has access to e-mail?
<a1983>to user email
<[ARP]hoijui_irc>only the server software?
<aegis>server admins and software only
<aegis>anyone with root access to the server, but that list might go down
<aegis>if moved to my server it would only be a few select lobby admins
<[ARP]hoijui_irc>we could safe the emials encrypted somehow
<[ARP]hoijui_irc>in the DB
<aegis>but that's easy to foil with root access
<[ARP]hoijui_irc>yeah but not automatically
<[ARP]hoijui_irc>i mean
<aegis>well you could just start up another uberserver pointed at the same db
<aegis>and reuse any password decryption we coded
<[ARP]hoijui_irc>like some malware that hops across servers and looks into DBs to look for entries that look like emial addresses
<[V]sheep>emails have to be stored with reversible encryption to be processed...
<[ARP]hoijui_irc>yeah, but not automatically
<aegis>if server is compromised we have bigger issue
<[ARP]hoijui_irc>no bigger issue then provacy of our users!
<aegis>anyway my personal server is very hardened and running only very limited services
<aegis>the one I'd move this to anyway
<a1983>What to do with old users
<[ARP]hoijui_irc>that would make us even moredependent on you
<_koshi_>there's no need to do anything with current users
<aegis>we can backup to another reliable third-party
<[V]sheep>only secure way is to store emails on another system + have some kind of api from main server
<aegis>api would just make things complicated.
<[V]sheep>for current users, they can add their email with new command (CHANGEEMAIL) so they are safe from future memory loss
<aegis>double-E always bugged me :)
<aegis>hoijui - I'm very emotionally/financially stable and I've been around for some 6+ years
<[ARP]hoijui_irc>hehe :D :D
<aegis>I'm not going to ragequit and I take this responsibility seriously
<aegis>not planning to pull a cup or w/e
<[ARP]hoijui_irc>give me official certificate for emotional stability pls! :-)
<[ARP]hoijui_irc>yeah but you are not around always
<[V]sheep>do i need to redact this out from minutes? :P
<[ARP]hoijui_irc>i was more thinking on daily stuff
<aegis>like what
<[ARP]hoijui_irc>changeing version
<aegis>I always respond to emails
<[ARP]hoijui_irc>applying patches
<aegis>I'm in lobby because of version change, jk emailed me
<_koshi_>back on topic?
<[ARP]hoijui_irc>well.. for me it is never ok to give more power to less
<[ARP]hoijui_irc>yeha, odes not matter here
<[ARP]hoijui_irc>so .. 3 new commands?
<[ARP]hoijui_irc>someone likes ot make proposal draft?
<_koshi_>i would till next sunday
<[ARP]hoijui_irc>lobby protocol patches preffered
<_koshi_>that too
<[ARP]hoijui_irc>nice :-) thanks
<[V]sheep>which *3* new commands ?
<[ARP]hoijui_irc>ouh.. not 3 new commands..
<aegis>I'll implement and put up on testing server
<_koshi_>well, one isn't new
<[ARP]hoijui_irc>change to REGISTER CHANGEEMAIL and....
<aegis>I'd say SETEMAIL to avoid EE in command
<[ARP]hoijui_irc>ah k :-)
<[V]sheep>i dont know what 3rd command is about... maybe some way to query it for mods ? not sure i like it though
<_koshi_>if you want to implement that right away aegis, you should do the doc too. otherwise i'm just writing besides the imp
<[V]sheep>oh right :)
<aegis>_koshi_: all commands in uberserver are self-documented now :P
<_koshi_>no they ar enot
<[ARP]hoijui_irc>aegis, we agreed that first stuff has to be documentedin xml
<[V]sheep>everything seems obvious... except semantics of registration if we want to be able to slide in validation...
<[ARP]hoijui_irc>then we vote on it, then it can be implemented
<aegis>you don't get to tell me when I can implement things
<[ARP]hoijui_irc>yeah we do
<aegis>nope :P
<aegis>you can suggest how to change my implementation, and when I shouldn't push to live server
<aegis>but there's no reason I shouldn't be able to work on it while it's in draft :D
<[ARP]hoijui_irc>yeah ok
<aegis>_koshi_: all commands client sends to server
<aegis>the other way isn't because I haven't abstracted that fully yet
<_koshi_>we do have a dedicated document for this stuff for a reason
<aegis>I'm not saying this as a way to avoid updating dedicated doc
<aegis>I'm saying I'll *already* be writing something of a doc so it's not a stretch.
<[V]sheep>about lostpasswd... i think people also forget about their username sometimes (...) ... do we want to handle this case ?
<aegis>sounds good actually
<aegis>we could have a command to email them all the usernames registered to their email?
<[PinK]halcyon>yeah ppl rename a LOT
<aegis>or they could not delete emails
<[PinK]halcyon>if you rename, then quit spring for a few months, come back, you have no idea what you were named..almost happened to me
<[ARP]hoijui_irc>that would requrie a web interface though, no?
<aegis>lostuser, lostpass?
<aegis>lobbies can do that without web interface
<[V]sheep>just make sure in implementation that you dont return an error if email is not found so its not possible to detect if some email has registered or not...
<[ARP]hoijui_irc>ah yeah ok
<aegis>sheep, to do that you need to prevent user from knowing if it worked
<[PinK]halcyon>users could spam lostuser
<aegis>you can kick them if they use it and rate-limit connections/ban automatically
<aegis>kick = you can only use it once per connection
<aegis>iirc I added a rate-limit in iptables already
<[V]sheep>yes... he must check his email to see if he got something, not rely on his lobby to tell if it worked or not. if he forgot his username, password AND email, he doesnt deserve to get his account back :)
<[PinK]halcyon>then he should contact a mod
<[PinK]halcyon>or aegis directly
<aegis>okay :)
<[PinK]halcyon>but it's not relevant
<[PinK]halcyon>it's such a unusual scenario :)
<[PinK]halcyon>well I mean..i'm assuming mods don't get much control in this?
<aegis>what kind of control?
<[PinK]halcyon>changing emails for a user who lost theirs
<[PinK]halcyon>if they could convince the mod somehow that they are who they say
<aegis>they can change password for users already
<aegis>isn't that enough?
<aegis>change password -> user logs in and changes email
<[PinK]halcyon>in fact yes it is
<[PinK]halcyon>nvm :)
<danil_kalina>not enough
<[PinK]halcyon>do you want to explain that or should we continue?
<danil_kalina>we should be able to retrive an account if we forgot password
<a1983>and e-mail?
<[PinK]halcyon>LOSTPASSWD <account> would send password to email
<[PinK]halcyon>from another account
<[V]sheep>this would be handled by the LOSTPASSWORD command (or w/e) ... that does something not defined by spec, but probably send a one-time token to reset password through web interface
<[PinK]halcyon>if I understood correctly
<_koshi_>reset/lostpasswd would not require login obviously
<[V]sheep>not resetpassword... you dont want people to be able to troll someone else by resetting their password too easily
<_koshi_>eh, right
<[V]sheep>worst they should be able to do is cause an email to be sent
<[PinK]halcyon>sounds good
<[CN]Zydox>perhaps the LISTPASSWD should take the e-mail account as arg instead of user?
<[PinK]halcyon>this is obviously..a functionality long needed :)
<[CN]Zydox>So that trolls can't spam a user with e-mails
<[ARP]hoijui_irc>yeah email as arg, and send accoutn name and passwd
<_koshi_>alright, conclusion: i'll draft doc, aegis drafts imp, next meeting we'll see what fits where and vote

=== Protocol specification: about conversion from DTD to XSD ===

<_koshi_>next up: convert Protocol.dtd to Protocol.xsd
<[PinK]halcyon>it would be good if the password was flagged, so that the user is told to change psw when they log in again
<[PinK]halcyon>since email is not necessarily secure, although nobody really wants to hack into a spring account
<[ARP]hoijui_irc>we currently have a DTD, and i though we should probably switch to XSD
<_koshi_>just in case I have no clue what that means
<[ARP]hoijui_irc>they are both good for validatiing an xml (and i think other stuff.. which we do not care about)
<_koshi_>can you tell me in one line?
<[ARP]hoijui_irc>as in.. they say what tags can be used in which structure, whihc attirbutes hwere
<[ARP]hoijui_irc>and what value ranges and such
<[ARP]hoijui_irc>it was suggeted that we should probably add value types to command arguments
<[ARP]hoijui_irc>i am not sure if that is possible with DTD
<[ARP]hoijui_irc>i though not
<[ARP]hoijui_irc>or only in a limited way
<[ARP]hoijui_irc>with XSD is shoudl be possible
<_koshi_>so basically a stricter grammar?
<[ARP]hoijui_irc>we could define whihc args are ints, which are bool, and os on
<_koshi_>that would be a nice to have indeed
<_koshi_>and I guess the auto parser guys would liek that too
<[ARP]hoijui_irc>it means we do not have to repeat how a bool has to look like for every bool argument for example, and it allows for nicer transforming and automatic processing
<[ARP]hoijui_irc>yeah :-)
<[ARP]hoijui_irc>i am quite noob in this though
<[V]sheep>i'd like to have these extra details, but i dont have an opinion on DTD vs XSD and managed to dodge xml related work for quite some time, so i'm clueless on details...
<[ARP]hoijui_irc>i was lookign for auto ocnversion tools
<[ARP]hoijui_irc>but they seem all to be .. way to complex and buggy, or commercialy licnesed only
<[ARP]hoijui_irc>the DTD is not big
<[ARP]hoijui_irc>so... this is kind of a request...
<[PinK]halcyon>could a script do it automatically?
<[ARP]hoijui_irc>woudl anyone want to try to do that?
<[ARP]hoijui_irc>yes but that woudl surely take a lot more time
<[ARP]hoijui_irc>the DTD is only..
<[V]sheep>maybe we can discuss this here during the week and see how to do it... we can probably just write the xsd from scratch while learning the best way to specify types...
<[ARP]hoijui_irc>~30 lines of actual code
<[PinK]halcyon>maybe sheep wants to do it more?
<[ARP]hoijui_irc>yeah that sounds good :-)
<_koshi_>i'd +1 sheep here
<[ARP]hoijui_irc>yeah i was also thinking on him :D
<[PinK]halcyon>he's the auto parser guy after all
<[ARP]hoijui_irc>but of course we can also do it ollaboratively
<[ARP]hoijui_irc>maybe etherpad if you want
<_koshi_>i mean the discussing this outside of this meeting hoi :)
<[ARP]hoijui_irc>ah k :D
<[ARP]hoijui_irc>then next

=== about FORCEJOIN (and random chat about linux lobbies) ===

<_koshi_>server development/documentation / what was done this week
<_koshi_>we now have FORCEJOIN implementation in boith SpringLs and SpringLobby
<_koshi_>and as of a couple hours ago that works too
<[ARP]hoijui_irc>all that was done on protocol spec and SpringLS cna be seen in the git repos on github under the spring user in the master brancehs
<[ARP]hoijui_irc>these are untested though
<_koshi_>and not in SL yet
<danil_kalina>nice. but FORCEJOIN is obsolete
<_koshi_>i don't think so
<[ARP]hoijui_irc>you mean.. it will probably be obsolete soon
<[PinK]halcyon>it's obsolete if the server-side hack stuff isn't necessary
<[PinK]halcyon>but..also consider we don't have forcejoin in uberserver, it's not like it has been truly added then
<danil_kalina>a1983 suggested a better way
<danil_kalina>but you have already done everything
<[PinK]halcyon>yes but, new say was something new in the last meeting
<danil_kalina>ok, let's wait a couple of months
<_koshi_>http://etherpad.springrts.com/poQoTD5izX boils down to 'have common autohost interface, use new say'
<[ARP]hoijui_irc>ah yeah... athts an other reason for XSD
<[ARP]hoijui_irc>if we know how it works, we can also use it for the new protocol spec document
<danil_kalina>I think
<_koshi_>then I see no reason to go back on forcejoin, because with new say there will be no legacy compat
<danil_kalina>didn't understand you properly, but it sounds correct
<_koshi_>and that was one of the biggest wants for this mechanism, no?
<[PinK]halcyon>get it right the first time, save lobby devs and server devs the trouble of implementing forcejoin in a way that will be changed
<[ARP]hoijui_irc>it means, that if we use newsay for match-making instead of FORCEJOINBATTLE, then old lobbies will fail
<[ARP]hoijui_irc>or say.. ignore
<danil_kalina>fuck old lobbies
<[ARP]hoijui_irc>and thuis match making algo will fail
<a1983>Why? They already failed, isn't it?
<[PinK]halcyon>danil_kalina: this is going into meeting minutes :)
<[ARP]hoijui_irc>old lobbies are watching you!
<[PinK]halcyon>licho said several times, he only cares for zklobby and sl
<[PinK]halcyon>which i'm sure will have no probs staying up-to-date
<_koshi_>there's easily a year old SL version actively used still
<[PinK]halcyon>and nobody else is likely to use forcejoin for a while
<_koshi_>i do not want to fuck them
<a1983>Of cause licho will be frustrated
<danil_kalina>advance them
<[V]sheep>not sure, he said today notalobby should be announced as best linux lobby for zk... so nota too
<_koshi_>if it's simple to avoid
<[PinK]halcyon>users are expected to update their lobby
<[PinK]halcyon>and, it is the duty of the lobby to make sure they update
<danil_kalina>I didn't hear that
<[ARP]hoijui_irc>that is just not realistic on linux
<[PinK]halcyon>it's the only linux lobby atm :)
<[ARP]hoijui_irc>people use the lobby in hte repo
<[PinK]halcyon>repo needs to be updated
<[ARP]hoijui_irc>and no linux lobby will ever be up to date as of a few days in all linux distros in all versions
<_koshi_>no getting in the repo w/o being open source
<[PinK]halcyon>also linux users are tech savvy
<[ARP]hoijui_irc>no they are not
<_koshi_>they really aren't
<[PinK]halcyon>maybe not ubuntu users
<[PinK]halcyon>but the rest should know enough to compile their lobby to latest version
<[ARP]hoijui_irc>actually.. no
<[ARP]hoijui_irc>and even if, it is asked too muhc
<danil_kalina>of course no
<[PinK]halcyon>then keep repos updated
<[ARP]hoijui_irc>halc, that will never be reality
<_koshi_>[20:55:32] <_koshi_> no getting in the repo w/o being open source
<[V]sheep>well... i didnt check notalobby, but even dumb users can do ./configure && make && make install ... if there is no proper makefile, then its something else...
<[ARP]hoijui_irc>its like 10 distros, and most of them with mutliple versions
<[PinK]halcyon>it's only temporary until they get decently recent lobby versions
<[ARP]hoijui_irc>MAN, you are not listeninng..
<[ARP]hoijui_irc>it is not going to happen
<[PinK]halcyon>then stop using SL for linux
<danil_kalina>I am dumb and I don't wanna make: make and stuff like that
<[ARP]hoijui_irc>it does not matter which lobby
<[PinK]halcyon>use a lobby that is able to update itself
<[ARP]hoijui_irc>is that even legit for a general linux package to update itsself?
<[V]sheep>no :)
<_koshi_>quite the opposite in fact
<[ARP]hoijui_irc>do you think koshi goes through all this trouble cause he likes the old SL versions more then the new ones?
<danil_kalina>yes yes yes yes yes
<[ARP]hoijui_irc>or cause it is fun to suport old versions?
<danil_kalina>no no no no no
<[PinK]halcyon>as I said, compile it yourself, I know I did
<danil_kalina>fuck compile
<[PinK]halcyon>do you even know how buggy old sl is
<[ARP]hoijui_irc>lets look at it this way
<[ARP]hoijui_irc>all the people that have expernience say it is not possible
<[ARP]hoijui_irc>and the newbs who never it anything liek manage a linux package think it is
<[PinK]halcyon>it's funny bcs these noobs have been using linux for 10 years
<[ARP]hoijui_irc>try to do it for notalobby, and if you succeed for the next 2 or 3 years
<[PinK]halcyon>you really can't expect linux to be friendly like windows
<[ARP]hoijui_irc>we can think about "fucl old lobbies"
<[PinK]halcyon>if you can't even compile a package, why are you using linux
<danil_kalina>for fun
<_koshi_>alright, back on topic please
<[ARP]hoijui_irc>yeah please
<_koshi_>aegis: plans for forcejoin?
<_koshi_>licho said you had a legacy imp for !join already?
<aegis>iirc I tested and all major lobbies would respond properly to an implied battle join
<aegis>but that's a hack
<aegis>as in, pretend client had sent JOINBATTLE and send them BATTLEJOINED or whatever the next step was
<_koshi_>yes, [ARP]hoijui_irc did the same in springLS
<aegis>client.Send('JOINBATTLE %s %s' % (battle_id, battle.hashcode))
<[V]sheep>well... in what respect is it a hack? battlejoined specify which battle was joined... so there is no "race condition"
<aegis>yep, that's the server -> client JOINBATTLE command
<aegis>it's a hack because that's not in the protocol implementation
<_koshi_>so adding the FORCEJOINBATTLE itself would be simple for you?
<aegis>yeah, I'd just loop around and call JOINBATTLE with the client and battle id
<aegis>two lines of code, plus checks for permissions
<_koshi_>so imo question now is this:
<[PinK]halcyon>!join looks more elegant than forcejoin with this hack
<[ARP]hoijui_irc>protocol spec sais that server never makes you join a channel that you did not choose to join yourself (thats the hacky part)
<aegis>it can fail if client sets up data structures when they send JOINBATTLE instead of when they receive it
<aegis>as far as I know, this is not the case
<aegis>all the lobbies I tested trust a JOINBATTLE from the server
<_koshi_>take the solution we he have here or wait for unkown time for a unified AH interface
<aegis>as long as tasclient, springlobby, and zk work
<_koshi_>and implementation of the new say in lobby and server?

=== protocol commands for "data" communication between players and hosts/bots ===

<aegis>so the new say, what was that again?
<aegis>the one used for communication with autohosts / passing commands?
<_koshi_>not only ah, generic data interchange
<_koshi_>between users
<[ARP]hoijui_irc>a way to mark stuff that is said as beeing inter-lobby-client-commands
<[ARP]hoijui_irc>instead of chat
<aegis>another layer so you don't need to use sayprivate
<[V]sheep>kinda like EX modifier
<aegis>so like SAYDATA or sth
<aegis>you could pass data to a channel invisibly this way? :P
<aegis>that's cleaner than private messaging a bunch of users at once
<[ARP]hoijui_irc>the main idea was, to add a kind of isCommand bool param to all the *SAY* and *SAID* commands
<_koshi_>taht too aegis
<a1983>maybe DATASEND/RECEIVER but it is break existing command system
<aegis>so say, private, battle
<[PinK]halcyon>according to licho it was less work when using another param I think
<[PinK]halcyon>rather than a new cmd
<danil_kalina>Why not for Halcyon not to develope new lobby in scala and join to server development ?
<aegis>adding a param to say will be weird
<[PinK]halcyon>danil_kalina: indenting
<aegis>in fact that's really weird
<[PinK]halcyon>it is, and we all argued against it, but it was voted in anyway
<[V]sheep>i think the new command is nicer... only advantage of adding param to existing say is to provide some bawkward compatibiliy
<aegis>no point in backwards compat
<aegis>because you need to support the command to use it anyway
<aegis>leaving SAY as it is happens to be the *only* completely backwards-compat way
<aegis>if you add params that's not backwards-compat, that's leaking data
<aegis>and it's ugly
<[ARP]hoijui_irc>dont know what you mean
<aegis>I don't know of any lobbies that complain if server sends them a command verb they don't understand
<[ARP]hoijui_irc>it of course means the old clients do not get the commands
<[V]sheep>mine does, but its irrelevant :P
<aegis>but users will complain if they're seeing weird things like `SAID main aegis 1 INVITE #sy`
<a1983>fully agree, but it is break existing irc commands
<aegis>old clients don't *want* the commands
<aegis>because the commands don't do anything for old clients
<aegis>there's no reason for us to leak any other command type into SAY space
<aegis>so I don't know why this would be different
<aegis>ever connect to the server with telnet?
<aegis>it's almost unusable.
<aegis>and I've put things in place to make it a bit more bearable than tasserver was
<[ARP]hoijui_irc>cause oif PING PONG?
<aegis>no, you get way more commands than that
<aegis>then think if that was in each chat channel you were in
<aegis>it would be annoying and useless
<[PinK]halcyon>wasn't compflags intended to hide unknown cmds
<aegis>SAY has a very specific purpose atm
<aegis>it doesn't make sense to pollute that with data transfer
<aegis>even if client opts in
<aegis>that's the entire reason you wanted this protocol change, right? so you wouldn't need to data transfer with SAY? :P
<[ARP]hoijui_irc>werent licho and .. (koshi too?) pro the *SAY* argument?
<_koshi_>indeed the intention was to hide the toggle behind a comp flag
<[ARP]hoijui_irc>i cant get the reason together anymore
<aegis>adding an optional param in the middle of a command is weird
<aegis>even if that's hidden behind a compat flag
<aegis>on server end that would make SAY parsing a bit more ugly
<[V]sheep>parsing doesnt need more uglyness
<aegis>yes. it does.
<aegis>not sure if you've read uberserver source :P
<aegis>it's completely automatic right now, except for sentence args
<[ARP]hoijui_irc>one reason i think was.. casue we would need same set of commands anyway, so much duplication
<_koshi_>no one was against 'new say' proposal
<_koshi_>and yes, I was mostly fo rthe toggle to not have a duplicate for all
<[ARP]hoijui_irc>i reemmber it that way too
<[V]sheep>new say proposal was about the general idea, not specifics like new commands or command args...
<_koshi_>seeing as we have no draft to vote upon today
<aegis>nothing else uses toggle, so it also goes against pattern so far
<_koshi_>actually, practically a toggle is more work for me, I just thought it adds to spec unnecessarily
<_koshi_>fi I had to vote on toggle or not now (again?) i'd abstain
<_koshi_>sidenote: we prolly should start summarizing votes too, it's a pita to find in minutes atm
<aegis>cmd probably > data
<aegis>if for no other reason that 3 vs 4 chars :D
<aegis>channel is just say ;)
<_koshi_>lets change it :P
<aegis>that has little benefit
<[V]sheep>if we start changing stuff like that, then i have a LOT of proposals to make... :)
<aegis>I've been planning a protocol restructure that will make it easier for me to swap between entire protocol sets
<_koshi_>good lord guys, don't hopp on a silly joke
<aegis>allowing, for example, a web interface or IRC interface to be served while sharing most of the internal logic
<[V]sheep>yay xmpp to save us all :)
<aegis>I mostly need to decide how I want to abstract *outgoing* protocol before that will work
<[V]sheep>i'd say we should vote on either 1 or 2, then vote on the flavour (CMD vs DATA, or pre vs post parameter)
<[V]sheep>or we can postpone this until next week so we can add more awesome proposals
<_koshi_>+1 item 1
<[V]sheep>+1 item 1
<a1983>1. +1
<[PinK]halcyon>+1 item 1
<danil_kalina>1. +1
<_koshi_>anybody else? aegis bibim_ [CN]Zydox [ARP]hoijui_irc [1uP]CarRepairer
<[CN]Zydox>It's for the SAYDATA instead of SAY with args?
<[PinK]halcyon>see the etherpad
<[CN]Zydox>Yeah, looked at it
<[V]sheep>+1/0/-1 => 5/1/0
<_koshi_>no, the +1 have it :)
<[V]sheep>ok so now we vote on CMD vs DATA vs [your proposal] ?
<[CN]Zydox>+1 for DATA
<a1983>SAYCMD vs SAYDATA ?
<[V]sheep>DATA/any/CMD => 3/2/0
<a1983>+1 DATA
<[V]sheep>DATA/any/CMD => 4/2/0
<_koshi_>that's enough for DATA then

=== about lobbydev votes ===

<_koshi_>and if i'm bored enough sometime this week I shall make vote/minutes bot
<[V]sheep>would be nice... or integration with etherpad
<_koshi_>that would be kinda easy if we swicth to the node.js imp of etherpad

=== decision to postpone discution on the standardization of AH/bot commands sent via new SAY*DATA commands ===

<_koshi_>I propose we postpone the AH item on agend or have it for disccusion on forum
<_koshi_>since bibim_ and licho ain't here
<_koshi_>and they're kinda major to that
<_koshi_>so a1983, maybe make a new forum post somehwere in infrastucture dev if you want
<a1983>i'll try
<a1983>need suggest for forum thread
<[V]sheep>lobby protocol ?
<[ARP]hoijui_irc>you are talking about the inter-lobby-com-protocol thing?
<a1983>[ARP]hoijui_irc, yes
<_koshi_>no, i'm talking about stuff from http://etherpad.springrts.com/poQoTD5izX
<_koshi_>that is not about the mechanics of new say
<a1983>sorry, but I suppose that it was used to implement that protocol
<_koshi_>it's just not about the SAY itself
<[V]sheep>oh i didnt understand that... i was proposing a new forum "section", sister to "lobby client" to focus on protocol issues only
<a1983>aah, yeap
<[PinK]halcyon>who wrote that they could maintain it?
<a1983>I :)
<_koshi_>i think infrastructure development is very appropiate already sheep
<[V]sheep>past lobbydev meeting minutes went to lobby-client already
<[V]sheep>not sure we need to change, but since protocol changes affect server + client, thats why i was proposing a new section
<_koshi_>tbhi don't care much, I could see minutes in infra dev too
<_koshi_>now unless someone has a burning desire to discuss custom properties right now, I'd say postpone that yet again
<[V]sheep>yes we just passed the 2hours mark...
<a1983>But custom properties are awesome )
<[V]sheep>oh no we started late... but custom props are so awesome we should wait a week more... :)
<[V]sheep>so we get major players
<_koshi_>alright, meeting end ------------------------------------------------------------
0 x

User avatar
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Lobbydev meeting minutes 2012-03-11

Post by Licho » 15 Mar 2012, 04:27

So what did you actually decide? FORCEJOIN as well as data param to SAY commands was decided on previous meeting.
No point changing it...

SAY is better with param because all operations are needed - PM,channel,battle.
And compflag can simply hide data messages from old clients.

Extra command -> extra code in lobbies for processing. Param is simpler to handle in this case because processing stays the same.

Im highly annoyed that people who dont maintain significant lobby server based code have same voice on this.

As for bot emails .. thats a bit silly consider springie - one springie runs tens of autohosts and new are created on demand - including new accounts. All of them need bot flag. They are made without user interaction.

Anyway considering that spring is dying bot owner issue is hardly a pressing one :)
0 x

User avatar
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Lobbydev meeting minutes 2012-03-11

Post by hoijui » 15 Mar 2012, 08:36

the most important reason to make meeting minutes, is to have the Summary at the end. so as a tip to whoever does the meeting minutes in the future, do the summary really soon after the meeting, at best the same evening (or even during the meeting), cause this way you still rememeber, and thus do not have to re-read the whole meeting again.
the summary should list points like.. what was decided on whihc issues, and who promised to implement/document what (possibly until when).
Not that important, but considering it is much easier to make, it should still always be there... the Agenda (list of topics discussed, given in the beginning).

you miss both of these. please add at least the summary.

@Licho (SAYDATA)
either i never knew, or i forgot again but.. i see no big difference in the additional param vs the additional commands. code wise, they have to be treated differently anyway, at least on the client side, so there is a switch for command/not-command in code, whether that is at the command-name level, or a bit later on the isCommand argument, makes no actual difference in maintainability. on the server side, it is also possible to basically have two stub classes/methods for the two flavors of a SAY command (normal/chat and DATA), and forward requests to a single class/method where they are actually handled, or do it the other way around: in case of a single command with the argument isCommand, you could have one stub class/method and forward to two different classes/methods for actual handling code, depending on the argument value.
0 x

User avatar
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Lobbydev meeting minutes 2012-03-11

Post by Licho » 15 Mar 2012, 12:02

You wont just need DATA, you will need several "DATA" commands for private, battle and channel messages if you want to follow how say is done...

Which is why I said you should add parameter instead of spamming 6 new entries for docs...

You are just adding stupid complexity for no good reason.
0 x

Posts: 834
Joined: 19 May 2009, 21:10

Re: Lobbydev meeting minutes 2012-03-11

Post by SirMaverick » 15 Mar 2012, 14:26

hoijui wrote:the most important reason to make meeting minutes, is to have the Summary at the end.
0 x

User avatar
Former Engine Dev
Posts: 4342
Joined: 22 Sep 2007, 09:51

Re: Lobbydev meeting minutes 2012-03-11

Post by hoijui » 15 Mar 2012, 16:13

i wrote flavors of the SAY command, which indicates i knew about that.
it makes no difference. in one case you have to add code for handling the argument for each class/function (flavour of SAY), and in the other case you have to add one class/function for each flavour. it is O(n) in both cases.
the same argument applies for the documentation.
0 x

User avatar
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Lobbydev meeting minutes 2012-03-11

Post by Licho » 15 Mar 2012, 16:47

How do you know it makes no difference? I wrote most currently connected lobby server clients. If I say it makes a difference you can bet it does. ..

Meh bunch of random people deciding about things they have no clue about with equal vote.. random breaking engine changes, spring will be dead within few months i bet..
0 x

Posts: 834
Joined: 19 May 2009, 21:10

Re: Lobbydev meeting minutes 2012-03-11

Post by SirMaverick » 15 Mar 2012, 17:34

Licho wrote:How do you know it makes no difference?
As hoijui said you need to handle more cases either on command or parameter level. Can you show us how there is a difference? Is there a good example in ZK Lobby source?
Meh bunch of random people deciding about things they have no clue about with equal vote.. random breaking engine changes, spring will be dead within few months i bet..
0 x

User avatar
Lobby Developer
Posts: 1058
Joined: 14 Aug 2007, 16:15

Re: Lobbydev meeting minutes 2012-03-11

Post by koshi » 15 Mar 2012, 17:46

Whether one hides the new meaning of SAY via a toggle or one adds separate commands is no different in informational complexity.
A given implementation may make one way easier over the other ofc. For me adding new commands instead of forking logic given a command parameter is simpler both in libspringlobby and the python bot framework.
0 x

User avatar
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Lobbydev meeting minutes 2012-03-11

Post by Licho » 15 Mar 2012, 18:44

Im mostly annoyed that you OVERRODE decision of previous meeting without people whom it involves present to comment!

Read minutes from last meeting:
Proposal X (SAY with extra flag for filtering in old lobbies) was accepted.
And now you revert to something else seriously WTF?

Can I propose SAY with extra flag again on the next meeting without koshi and aegis and get bunch of people who made lobby spambots to vote for the proposal?

0 x

User avatar
Posts: 1571
Joined: 07 Feb 2005, 21:30

Re: Lobbydev meeting minutes 2012-03-11

Post by Cheesecan » 15 Mar 2012, 19:17

Add a parameter to data which indicates area¿

You could change votes to weigh in user number for that lobby.. seems more democratic, I wouldn't mind personally.. server devs could have veto right. Spring United Lobby Council.
0 x

User avatar
Lobby Developer
Posts: 1058
Joined: 14 Aug 2007, 16:15

Re: Lobbydev meeting minutes 2012-03-11

Post by koshi » 15 Mar 2012, 21:00

I see nothing wrong with changing a proposal that doesn't have a documentation draft yet. Feel free to bring it up again next sunday.
Could do with less pictures and name calling and with more arguments that might actually sway people though, but that's ofc just my opinion.
0 x

Post Reply

Return to “Lobby Meeting Minutes”