Lobby :: Dev meeting minutes 2012.04.23
Posted: 23 Apr 2012, 15:13
Lobby Dev Meeting 2012-04-23 20:54:16.873488
Agenda
Agenda Item 1:minutes -------------------------
_koshi_: welcome everyone
_koshi_: I'm volunteering again, since i'm not quite done with the auto script thingies
Agenda Item 2:SAYBATTLEPRIVATE & SAYBATTLEPRIVATEEX -------------------------
_koshi_: aegis and or licho wanted to prepare a draft for that
[ARP]hoijui_irc: does anyone know where licho is?
_koshi_: nope
[ARP]hoijui_irc: ok
[ARP]hoijui_irc: aegis seems to be away
_koshi_: i'm guessing the draft didn't happen again, so we can table this point
[ARP]hoijui_irc: i agree
Agenda Item 3:new drafts -------------------------
_koshi_: EXIT https://github.com/spring/LobbyProtocol/compare/exit
_koshi_: and
_koshi_: GETINGAMETIME https://github.com/spring/LobbyProtocol ... ingametime
_koshi_: i somewhat doubt they're worth discussing unless my wording is off/wrong?
bibim_: hum, uberserver accepts a parameter for EXIT command (exit reason)
[ARP]hoijui_irc: "before severing the connection to indicate a clean and deliberate disconnect" maybe use a more common people word then severing, but that is very minor
[ARP]hoijui_irc: and yeah.. i guess an optional reason arg makes sense
_koshi_: sentence?
_koshi_: i mean should it be a sentence arg?
[ARP]hoijui_irc: ahh yeah, i woudl say so
_koshi_: alright, i'll change that
[ARP]hoijui_irc: ook
_koshi_: anything else?
[ARP]hoijui_irc: looks good to me otherwise
bibim_: yeah seems ok
danil_kalina: +
_koshi_: alright, next
Agenda Item 4:remaining undocumented uberserver commands -------------------------
_koshi_: since aegis and licho both aren't really here, i guess we'll skip the openbattleex stuff again
[ARP]hoijui_irc: yeahh!
_koshi_: unless one of you guys researched that?
aegis: I'm here now.
danil_kalina: :D
[ARP]hoijui_irc: hey
danil_kalina: I don't remember exactly, but there is only two new parameters
danil_kalina: like name of the engine
aegis: engine, version
danil_kalina: and it's version
aegis: right before the sentence args
danil_kalina: to activate them you should add exstensional parameter when connect
aegis: if engine = spring, version = current_version or current_version.0, it will still send normal BATTLEOPENED command to regular clients
danil_kalina: that was done so many times ago :D
danil_kalina: ~ a month ?
_koshi_: what was done?
danil_kalina: supporting that
_koshi_: nope
_koshi_: not at all
danil_kalina: in a lobby
danil_kalina: we have done
[ARP]hoijui_irc: is there a protocol proposal for it?
_koshi_: nope
[ARP]hoijui_irc: k
_koshi_: not that i'm aware
[ARP]hoijui_irc: so it was not done
_koshi_: correct
_koshi_: other than that mapping to plain BATTLEOPENED, you're doing no logic server site, aegis?
danil_kalina: this was done for games which are not ready for new spring version
_koshi_: can you draft the protocol extension then, danil_kalina/aegis?
danil_kalina: we ignore the version of spring which server send. just check the version in battleroom
danil_kalina: aegis, where are you ? :D
[ARP]hoijui_irc: yeah yeah, i get it..
[ARP]hoijui_irc: "me russian, me noo good english, me no can write protocol proposal!"
[ARP]hoijui_irc: lazy bastards!
[ARP]hoijui_irc:
aegis: still here
[ARP]hoijui_irc: aehm.. was not meant to be serious
aegis: logic is almost identical to BATTLEOPENED
danil_kalina:
aegis: we should discuss what to do with *different* version battles
_koshi_: like what? the clinet would either list them for its user or not
danil_kalina: give me a link to etherpad
danil_kalina: I will show you protocol
danil_kalina: too much text
_koshi_: http://etherpad.springrts.com/
danil_kalina: :)
danil_kalina: thanks
danil_kalina: http://etherpad.springrts.com/iKcJFfNpXH
aegis: _koshi_: backwards compat for clients who don't implement extended battles
aegis: licho's original stance was "the lobby should see the battle so they know they're missing something" if it's for a different engine/version
aegis: I can show them the battle with modified description and give them a descriptive error on join, I can hide the battle...
[ARP]hoijui_irc: danil... (why did you use C comments in XML syntax?) you just added two arguments?
[ARP]hoijui_irc: we need a description
[ARP]hoijui_irc: so that someone that never attended the meeting or read any lobby client or server code knows how to implement his client/server
_koshi_: if the client doesn't support versioned battle via new protocol it's of no use to present them to it
_koshi_: "so they know they're missing something" is of no value if i need to implement additional logic to filter those
[ARP]hoijui_irc: also.. seeing a battle you cant join and fail to join wiht no explanation.. is very bad
_koshi_: exactly
[ARP]hoijui_irc: 1% of users will ask in main why is that, rest will just hate us
[ARP]hoijui_irc: also.. this was kind of a method of pressure of licho agaisnt SL, which now does not make sense anymnore
danil_kalina: need to implement auto spring download
[ARP]hoijui_irc: since we have this meeting and protocol changes and agreements and so on
danil_kalina: new Game version - we have, new Map - we have
danil_kalina: new Spring Engine - no
[ARP]hoijui_irc: ? is that related to the topic?
aegis: _koshi_: if you're implementing logic, you can implement the new command
danil_kalina: yes
_koshi_: exactly aegis
danil_kalina: why do we need different versions of Spring ?! for different games which can not be updated so fast like Spring Engines issued
[ARP]hoijui_irc: isnt logic a more abstract word for implementation in code, in this scenario? .. i don;t get it
aegis: I'll make sure default behavior is to hide then
_koshi_: yes please
aegis: danil_kalina: or for testing new version reliably
[ARP]hoijui_irc: thanks
aegis: because hashes change by version
aegis: and sync changes
danil_kalina: it is obvious
danil_kalina: why do we need that discussion)
_koshi_: alright, so flesh out the protocol extension draft for next meeting accordingly
[ARP]hoijui_irc: i guess the main goal of this topic on the agenda is to ask for a proposal
_koshi_: yes, then we should be good to vote on that, potentially after hearing licho's input in the meantime
danil_kalina: you ask about the relation to the topic
_koshi_: agreed?
danil_kalina: of course they do ))
aegis: voting on what exactly?
[ARP]hoijui_irc: not now
[ARP]hoijui_irc: voting when hte xml protocol description of the commadn is done
aegis: k
_koshi_: right, that's what i meant to say
[ARP]hoijui_irc: mianly that is.. a good textual description, i think
[ARP]hoijui_irc: (what is missing)
_koshi_: next subitem: are there any more not yet documented commands in uberserver/springLs?
aegis: admin commands
danil_kalina: don't know any
danil_kalina: aha
aegis: most were never in the standard doc
aegis: because they can be sent by hand and respond in human-readable form
[ARP]hoijui_irc: you mean.. they were in TASServer too?
_koshi_: it's prolly debatable if we want to standardize them?
_koshi_: example maybe?
[ARP]hoijui_irc: i guess documenting them is good anyway, maybe we can mark them as optional or something
aegis: hoijui, most of my admin commands were copied from tasserver
aegis: afaik I implement all useful commands from tasserver
[ARP]hoijui_irc: ok
aegis: so when the transition happened admins could keep using the same command
aegis: only disabled forgemsg / forgereversemsg due to abuse potential
danil_kalina: The compat flag set on Login is "eb"[br][br]BATTLEOPENEDEX[br]Two new arguments[br]Between map hash and map name there are 2 new parameters:[br][br]- engine name[br]- engine version[br][br](for example "spring" and "88.0")[br][br][br]OPENBATTLEEX also has those parameters for battles you host
_koshi_: so do you think it's worth adding those since they prolly haven't diverged at all, yes?
[ARP]hoijui_irc: how else would admins know about them?
_koshi_: does the xml have a way to "tag"/express admin only commands already?
[ARP]hoijui_irc: or lobby devs that want to implement an admin panel or soemthing
aegis: extra behavior: server will hide battles with different engine/version if you don't send that compat flag, and server will *only* send you BATTLEOPENEDEX if you specify the flag
[ARP]hoijui_irc: no, does not have that
aegis: admins have internal docs
_koshi_: that would be a good additon then imo
[ARP]hoijui_irc: mm ok
_koshi_: so we can display/transofrm that into a sep section
_koshi_: in html output
[ARP]hoijui_irc: yeah, would be good additial.. to the new XSD stylesheet :D
aegis: imo worst place to find out about admin commands for admins would be an xml doc of the whole server somewhere
aegis: because admins/mods != lobby devs
[ARP]hoijui_irc: if it was a tag, you can just show these
aegis: but admin panel isn't bad thing.
aegis: iirc tasserver implemented some admin operations directly
[ARP]hoijui_irc: and as it is on git, and we have a site that auuto generates html form latest protocol version alreayd.. it woudl be easy ot add an other HTML doc with only admin command
[ARP]hoijui_irc: s
aegis: in context menu
[ARP]hoijui_irc: mmm ok
aegis: as well as springlobby?
_koshi_: stuff thru chanserv only, if memory servers
_koshi_: serves*
_koshi_: no idea what's "proper" wrt xml "tag" though
[ARP]hoijui_irc: sheep once said he would look into XSD
[ARP]hoijui_irc: though we dont need that for this one
[ARP]hoijui_irc: hmm yeha.. could be soemthing like an attribute for the command itssels
[ARP]hoijui_irc: its self
[ARP]hoijui_irc: eg <Command Admin="true">
[ARP]hoijui_irc: or something like:
_koshi_: and no attribute present --> false
_koshi_: or would one want to transform all already present commands?
[ARP]hoijui_irc: <Command><Tags><Tag>Admin</Tag>...
[ARP]hoijui_irc: dont know what you mean. koshi
_koshi_: if we introduce a new attribute
[ARP]hoijui_irc: we would have two docs with transform info
_koshi_: would we need to add that attribute to all commands?
[ARP]hoijui_irc: ahh no
[ARP]hoijui_irc: can have default one
_koshi_: damn lag, brb
_koshi_: back
_koshi_: i can't decide for or against either method tbh
[ARP]hoijui_irc: second method is more flexible
[ARP]hoijui_irc: i like it more
[ARP]hoijui_irc: and the additional chars it costs should not matter too muhc, as there are few admin commands
[ARP]hoijui_irc: and as soon as we get an other tag, this method is better already
[ARP]hoijui_irc: hmm.. ok .. i odn't know
[ARP]hoijui_irc: don't care muhc
bibim_: +1 I guess...
danil_kalina: right
_koshi_: please use the command so its recorded
danil_kalina: abstain
_koshi_: vote 0 then danil_kalina
Vote: add optional <TAGS> to commands
Result 4
danil_kalina: sleeping timr
_koshi_: gn
danil_kalina: cya
Agenda Item 5:server development/documentation / what was done this week -------------------------
_koshi_: any progress wrt forcejoin aegis? that was a topic last meeting
aegis: basically have two fulltime jobs right now, been hard to find time without scheduling and I haven't scheduled
aegis: is forcejoin the only one I need to implement in main server atm? have the email commands been finalized?
aegis: I'll set a reminder for tonight
_koshi_: the email stuff is finalized, but no one has begun implementing anything afaic
aegis: k, that'll be second priority
_koshi_: forcejoin is ready on SL side and licho will prolly have little diff. to change from his !join hack
[ARP]hoijui_irc: i have begann to implement email stuff
[ARP]hoijui_irc: but it is not working/testable yet
_koshi_: alright
_koshi_: anything else to note for this topic or are we done for today?
[ARP]hoijui_irc: me done for today
Summary
Agenda
- minutes
- SAYBATTLEPRIVATE & SAYBATTLEPRIVATEEX
- new drafts
- remaining undocumented uberserver commands
- server development/documentation / what was done this week
- bibim_
- danil_kalina
- aegis
- [ARP]hoijui_irc
- _koshi_
Agenda Item 1:minutes -------------------------
_koshi_: welcome everyone
_koshi_: I'm volunteering again, since i'm not quite done with the auto script thingies
Agenda Item 2:SAYBATTLEPRIVATE & SAYBATTLEPRIVATEEX -------------------------
_koshi_: aegis and or licho wanted to prepare a draft for that
[ARP]hoijui_irc: does anyone know where licho is?
_koshi_: nope
[ARP]hoijui_irc: ok
[ARP]hoijui_irc: aegis seems to be away
_koshi_: i'm guessing the draft didn't happen again, so we can table this point
[ARP]hoijui_irc: i agree
Agenda Item 3:new drafts -------------------------
_koshi_: EXIT https://github.com/spring/LobbyProtocol/compare/exit
_koshi_: and
_koshi_: GETINGAMETIME https://github.com/spring/LobbyProtocol ... ingametime
_koshi_: i somewhat doubt they're worth discussing unless my wording is off/wrong?
bibim_: hum, uberserver accepts a parameter for EXIT command (exit reason)
[ARP]hoijui_irc: "before severing the connection to indicate a clean and deliberate disconnect" maybe use a more common people word then severing, but that is very minor
[ARP]hoijui_irc: and yeah.. i guess an optional reason arg makes sense
_koshi_: sentence?
_koshi_: i mean should it be a sentence arg?
[ARP]hoijui_irc: ahh yeah, i woudl say so
_koshi_: alright, i'll change that
[ARP]hoijui_irc: ook
_koshi_: anything else?
[ARP]hoijui_irc: looks good to me otherwise
bibim_: yeah seems ok
danil_kalina: +
_koshi_: alright, next
Agenda Item 4:remaining undocumented uberserver commands -------------------------
_koshi_: since aegis and licho both aren't really here, i guess we'll skip the openbattleex stuff again
[ARP]hoijui_irc: yeahh!
_koshi_: unless one of you guys researched that?
aegis: I'm here now.
danil_kalina: :D
[ARP]hoijui_irc: hey
danil_kalina: I don't remember exactly, but there is only two new parameters
danil_kalina: like name of the engine
aegis: engine, version
danil_kalina: and it's version
aegis: right before the sentence args
danil_kalina: to activate them you should add exstensional parameter when connect
aegis: if engine = spring, version = current_version or current_version.0, it will still send normal BATTLEOPENED command to regular clients
danil_kalina: that was done so many times ago :D
danil_kalina: ~ a month ?
_koshi_: what was done?
danil_kalina: supporting that
_koshi_: nope
_koshi_: not at all
danil_kalina: in a lobby
danil_kalina: we have done
[ARP]hoijui_irc: is there a protocol proposal for it?
_koshi_: nope
[ARP]hoijui_irc: k
_koshi_: not that i'm aware
[ARP]hoijui_irc: so it was not done
_koshi_: correct
_koshi_: other than that mapping to plain BATTLEOPENED, you're doing no logic server site, aegis?
danil_kalina: this was done for games which are not ready for new spring version
_koshi_: can you draft the protocol extension then, danil_kalina/aegis?
danil_kalina: we ignore the version of spring which server send. just check the version in battleroom
danil_kalina: aegis, where are you ? :D
[ARP]hoijui_irc: yeah yeah, i get it..
[ARP]hoijui_irc: "me russian, me noo good english, me no can write protocol proposal!"
[ARP]hoijui_irc: lazy bastards!
[ARP]hoijui_irc:
aegis: still here
[ARP]hoijui_irc: aehm.. was not meant to be serious
aegis: logic is almost identical to BATTLEOPENED
danil_kalina:
aegis: we should discuss what to do with *different* version battles
_koshi_: like what? the clinet would either list them for its user or not
danil_kalina: give me a link to etherpad
danil_kalina: I will show you protocol
danil_kalina: too much text
_koshi_: http://etherpad.springrts.com/
danil_kalina: :)
danil_kalina: thanks
danil_kalina: http://etherpad.springrts.com/iKcJFfNpXH
aegis: _koshi_: backwards compat for clients who don't implement extended battles
aegis: licho's original stance was "the lobby should see the battle so they know they're missing something" if it's for a different engine/version
aegis: I can show them the battle with modified description and give them a descriptive error on join, I can hide the battle...
[ARP]hoijui_irc: danil... (why did you use C comments in XML syntax?) you just added two arguments?
[ARP]hoijui_irc: we need a description
[ARP]hoijui_irc: so that someone that never attended the meeting or read any lobby client or server code knows how to implement his client/server
_koshi_: if the client doesn't support versioned battle via new protocol it's of no use to present them to it
_koshi_: "so they know they're missing something" is of no value if i need to implement additional logic to filter those
[ARP]hoijui_irc: also.. seeing a battle you cant join and fail to join wiht no explanation.. is very bad
_koshi_: exactly
[ARP]hoijui_irc: 1% of users will ask in main why is that, rest will just hate us
[ARP]hoijui_irc: also.. this was kind of a method of pressure of licho agaisnt SL, which now does not make sense anymnore
danil_kalina: need to implement auto spring download
[ARP]hoijui_irc: since we have this meeting and protocol changes and agreements and so on
danil_kalina: new Game version - we have, new Map - we have
danil_kalina: new Spring Engine - no
[ARP]hoijui_irc: ? is that related to the topic?
aegis: _koshi_: if you're implementing logic, you can implement the new command
danil_kalina: yes
_koshi_: exactly aegis
danil_kalina: why do we need different versions of Spring ?! for different games which can not be updated so fast like Spring Engines issued
[ARP]hoijui_irc: isnt logic a more abstract word for implementation in code, in this scenario? .. i don;t get it
aegis: I'll make sure default behavior is to hide then
_koshi_: yes please
aegis: danil_kalina: or for testing new version reliably
[ARP]hoijui_irc: thanks
aegis: because hashes change by version
aegis: and sync changes
danil_kalina: it is obvious
danil_kalina: why do we need that discussion)
_koshi_: alright, so flesh out the protocol extension draft for next meeting accordingly
[ARP]hoijui_irc: i guess the main goal of this topic on the agenda is to ask for a proposal
_koshi_: yes, then we should be good to vote on that, potentially after hearing licho's input in the meantime
danil_kalina: you ask about the relation to the topic
_koshi_: agreed?
danil_kalina: of course they do ))
aegis: voting on what exactly?
[ARP]hoijui_irc: not now
[ARP]hoijui_irc: voting when hte xml protocol description of the commadn is done
aegis: k
_koshi_: right, that's what i meant to say
[ARP]hoijui_irc: mianly that is.. a good textual description, i think
[ARP]hoijui_irc: (what is missing)
_koshi_: next subitem: are there any more not yet documented commands in uberserver/springLs?
aegis: admin commands
danil_kalina: don't know any
danil_kalina: aha
aegis: most were never in the standard doc
aegis: because they can be sent by hand and respond in human-readable form
[ARP]hoijui_irc: you mean.. they were in TASServer too?
_koshi_: it's prolly debatable if we want to standardize them?
_koshi_: example maybe?
[ARP]hoijui_irc: i guess documenting them is good anyway, maybe we can mark them as optional or something
aegis: hoijui, most of my admin commands were copied from tasserver
aegis: afaik I implement all useful commands from tasserver
[ARP]hoijui_irc: ok
aegis: so when the transition happened admins could keep using the same command
aegis: only disabled forgemsg / forgereversemsg due to abuse potential
danil_kalina: The compat flag set on Login is "eb"[br][br]BATTLEOPENEDEX[br]Two new arguments[br]Between map hash and map name there are 2 new parameters:[br][br]- engine name[br]- engine version[br][br](for example "spring" and "88.0")[br][br][br]OPENBATTLEEX also has those parameters for battles you host
_koshi_: so do you think it's worth adding those since they prolly haven't diverged at all, yes?
[ARP]hoijui_irc: how else would admins know about them?
_koshi_: does the xml have a way to "tag"/express admin only commands already?
[ARP]hoijui_irc: or lobby devs that want to implement an admin panel or soemthing
aegis: extra behavior: server will hide battles with different engine/version if you don't send that compat flag, and server will *only* send you BATTLEOPENEDEX if you specify the flag
[ARP]hoijui_irc: no, does not have that
aegis: admins have internal docs
_koshi_: that would be a good additon then imo
[ARP]hoijui_irc: mm ok
_koshi_: so we can display/transofrm that into a sep section
_koshi_: in html output
[ARP]hoijui_irc: yeah, would be good additial.. to the new XSD stylesheet :D
aegis: imo worst place to find out about admin commands for admins would be an xml doc of the whole server somewhere
aegis: because admins/mods != lobby devs
[ARP]hoijui_irc: if it was a tag, you can just show these
aegis: but admin panel isn't bad thing.
aegis: iirc tasserver implemented some admin operations directly
[ARP]hoijui_irc: and as it is on git, and we have a site that auuto generates html form latest protocol version alreayd.. it woudl be easy ot add an other HTML doc with only admin command
[ARP]hoijui_irc: s
aegis: in context menu
[ARP]hoijui_irc: mmm ok
aegis: as well as springlobby?
_koshi_: stuff thru chanserv only, if memory servers
_koshi_: serves*
_koshi_: no idea what's "proper" wrt xml "tag" though
[ARP]hoijui_irc: sheep once said he would look into XSD
[ARP]hoijui_irc: though we dont need that for this one
[ARP]hoijui_irc: hmm yeha.. could be soemthing like an attribute for the command itssels
[ARP]hoijui_irc: its self
[ARP]hoijui_irc: eg <Command Admin="true">
[ARP]hoijui_irc: or something like:
_koshi_: and no attribute present --> false
_koshi_: or would one want to transform all already present commands?
[ARP]hoijui_irc: <Command><Tags><Tag>Admin</Tag>...
[ARP]hoijui_irc: dont know what you mean. koshi
_koshi_: if we introduce a new attribute
[ARP]hoijui_irc: we would have two docs with transform info
_koshi_: would we need to add that attribute to all commands?
[ARP]hoijui_irc: ahh no
[ARP]hoijui_irc: can have default one
_koshi_: damn lag, brb
_koshi_: back
_koshi_: i can't decide for or against either method tbh
[ARP]hoijui_irc: second method is more flexible
[ARP]hoijui_irc: i like it more
[ARP]hoijui_irc: and the additional chars it costs should not matter too muhc, as there are few admin commands
[ARP]hoijui_irc: and as soon as we get an other tag, this method is better already
[ARP]hoijui_irc: hmm.. ok .. i odn't know
[ARP]hoijui_irc: don't care muhc
bibim_: +1 I guess...
danil_kalina: right
_koshi_: please use the command so its recorded
danil_kalina: abstain
_koshi_: vote 0 then danil_kalina
Vote: add optional <TAGS> to commands
Result 4
- bibim_: 1
- danil_kalina: 0
- aegis: 1
- [ARP]hoijui_irc: 1
- _koshi_: 1
danil_kalina: sleeping timr
_koshi_: gn
danil_kalina: cya
Agenda Item 5:server development/documentation / what was done this week -------------------------
_koshi_: any progress wrt forcejoin aegis? that was a topic last meeting
aegis: basically have two fulltime jobs right now, been hard to find time without scheduling and I haven't scheduled
aegis: is forcejoin the only one I need to implement in main server atm? have the email commands been finalized?
aegis: I'll set a reminder for tonight
_koshi_: the email stuff is finalized, but no one has begun implementing anything afaic
aegis: k, that'll be second priority
_koshi_: forcejoin is ready on SL side and licho will prolly have little diff. to change from his !join hack
[ARP]hoijui_irc: i have begann to implement email stuff
[ARP]hoijui_irc: but it is not working/testable yet
_koshi_: alright
_koshi_: anything else to note for this topic or are we done for today?
[ARP]hoijui_irc: me done for today
Summary
- again no SAYBATTLEPRIVATE & SAYBATTLEPRIVATEEX draft
- EXIT gets an additional sentence param
- danil_kalina will flesh out a draft for OPENBATTLEEX,BATTLEOPENEDEX to be voted on next meeting
- Commands in protocol docs get an extensible <TAGS> element where necessary to document admin-only commands
- due to aegis' sever time restrictions no progress in uberser wrt new commands yet, hoijui has already started on the email stuff in SpringLS