| 1 |
15:00 < dowski> hey guys |
|---|
| 2 |
15:01 < fumanchu> hey |
|---|
| 3 |
15:01 < fumanchu> I haven't dissected your patch yet |
|---|
| 4 |
15:01 < dowski> np |
|---|
| 5 |
15:02 < fumanchu> I wondered why you didn't just use _appserver_state instead of "command"? |
|---|
| 6 |
15:02 < dowski> hehe - i thought about that this morning :-) |
|---|
| 7 |
15:03 < Lawouach> all true |
|---|
| 8 |
15:03 < Lawouach> :) |
|---|
| 9 |
15:03 < fumanchu> Lawouach, yes :) and I'm a Christian ;) |
|---|
| 10 |
15:03 < Lawouach> eh eh |
|---|
| 11 |
15:04 < dowski> i'll try to rework it to use _appserver_state this evening |
|---|
| 12 |
15:04 < fumanchu> dowski, so correct me if I'm wrong, but "command" is more about transitional states ("now trying to stop") rather than |
|---|
| 13 |
final states (like "stopped") right? |
|---|
| 14 |
15:05 < Lawouach> it's a funny "show" |
|---|
| 15 |
15:05 < Lawouach> it's debatable ! :) |
|---|
| 16 |
15:05 < Lawouach> ah ah |
|---|
| 17 |
15:06 < fumanchu> wait for it |
|---|
| 18 |
15:06 < fumanchu> Yom Kippur joke |
|---|
| 19 |
15:06 < Lawouach> yeah |
|---|
| 20 |
15:06 < Lawouach> i saw it:) |
|---|
| 21 |
15:07 < dowski> i guess "command" is more of an action-to-take flag at this point - so yeah, it is more transitional than final |
|---|
| 22 |
15:07 < fumanchu> so it shouldn't be a problem interspersing those between the _appserver_state values |
|---|
| 23 |
15:08 < fumanchu> should we make a ServerState obejct, with well-defined state transitions? |
|---|
| 24 |
15:09 < fumanchu> I'd like to see a state diagram in the docs |
|---|
| 25 |
15:09 < fumanchu> with allowance for "what's different when you run serverless" or initOnly |
|---|
| 26 |
15:10 < fumanchu> hm |
|---|
| 27 |
15:10 < fumanchu> maybe combine that with the current cherrypy._httpserver |
|---|
| 28 |
15:10 < fumanchu> into a single object |
|---|
| 29 |
15:10 < dowski> you're zooming past me now :-) |
|---|
| 30 |
15:11 < dowski> i need to get more familiar with the code |
|---|
| 31 |
15:11 < fumanchu> I'm just saying: take the individual functions and variables that we now have (that control httpserver and appserver |
|---|
| 32 |
state), and collect them all into a Server class |
|---|
| 33 |
15:11 < fumanchu> it's very data-driven right now, and might benefit from a more OO approach |
|---|
| 34 |
15:11 < dowski> gotcha - that sounds like a great idea |
|---|
| 35 |
15:12 < fumanchu> then you could have a definite "serverless" subclass |
|---|
| 36 |
15:12 < fumanchu> where the possible states are more clear |
|---|
| 37 |
15:12 < dowski> whew - it's amazing where an untrapped ctrl-c can lead :-) |
|---|
| 38 |
15:14 < fumanchu> :) |
|---|
| 39 |
15:14 < dowski> well, i'll probably continue with my initial patch idea for 2.1, unless you think otherwise |
|---|
| 40 |
15:14 < fumanchu> hopefully it leads to a better design ;) |
|---|
| 41 |
15:14 < fumanchu> sounds good |
|---|
| 42 |
15:15 < fumanchu> I'd like to see some docs about the goals though--a state diagram would be nice to have either in the book or the wiki |
|---|
| 43 |
15:16 < fumanchu> (I'm not sure how I feel yet about the behavior of _stop) |
|---|
| 44 |
15:16 < fumanchu> or maybe it's just the name |
|---|
| 45 |
15:18 < fumanchu> one thing that would be nice would be to write a test that raises KeyboardInterrupt inside a page handler |
|---|
| 46 |
15:24 < dowski> sorry, boss caught me to talk about backups :-) |
|---|
| 47 |
15:24 < fumanchu> np |
|---|
| 48 |
15:25 < fumanchu> I'm writing some start/stop tests right now, so we can nail down the current and desired behavior better |
|---|
| 49 |
15:25 < dowski> taking my patch into account, the names in server.py are definitely misleading now |
|---|
| 50 |
15:25 < fumanchu> yeah :/ |
|---|
| 51 |
15:25 < dowski> cool |
|---|
| 52 |
15:26 < dowski> that's another thing i need to digest - the test system |
|---|
| 53 |
15:26 < fumanchu> it's not trivial ;) |
|---|
| 54 |
15:27 < dowski> :-) |
|---|
