Conversation with #freelords at Wed 27 Mar 2013 09:11:01 PM CET on ulf82@irc.freenode.net (irc)
(09:11:11 PM) ulf82: So that was hopeless. :)
(09:11:29 PM) patton: yes
(09:11:43 PM) ulf82: Maybe we can try out the skype another time. :)
(09:11:50 PM) patton: i was almost sure the bandwidth was little
(09:11:54 PM) patton: sure
(09:11:57 PM) ulf82: give me one minute to open up everything
(09:12:24 PM) patton: but i must go to the other house in the country where i have a larger connection
(09:12:28 PM) patton: sure
(09:12:53 PM) ulf82: done.
(09:13:02 PM) ulf82: So what do we want to talk about today?
(09:13:24 PM) patton: ok basically i wanted to talk a bit about repository since it is very involved in task 177 and 187
(09:13:48 PM) ulf82: ok
(09:13:58 PM) patton: wanted to know what was your thoughts about that
(09:14:07 PM) ulf82: So try to present the problem, and then we can see
(09:14:11 PM) patton: ok
(09:14:38 PM) patton: well right now we have a repository that can handle basically a flat directory
(09:15:09 PM) patton: we have the root and then the subdir
(09:15:25 PM) patton: like /city or /army
(09:16:06 PM) patton: so while doing task 177 came out that Theodor tried to make different Drawers for each type
(09:16:15 PM) ulf82: well, you can add further levels, but this would be encoded in the name of the resource
(09:16:18 PM) patton: so a CityDrawer
(09:16:36 PM) patton: yes right now you can only play with resorce names
(09:16:47 PM) patton: like city_level1
(09:16:52 PM) patton: city_level2
(09:16:54 PM) patton: etc etc
(09:17:05 PM) patton: this is a bit annoying
(09:17:12 PM) patton: since we will have races
(09:17:24 PM) ulf82: yes, you will definitely need a further hierarchy
(09:17:30 PM) patton: and we will be forced to put all resources in the same directory
(09:17:47 PM) patton: but this is not good
(09:18:03 PM) ulf82: Well, what speaks against calling a resource "orc/warrior"
(09:18:03 PM) patton: at least we need a deeper path
(09:18:05 PM) ulf82: ?
(09:18:27 PM) ulf82: It would be correctly searched in the subdirectory orc.
(09:18:36 PM) patton: yes sure but you need to know that
(09:18:48 PM) patton: and it will be hardcoded somewhere
(09:18:58 PM) patton: not so good
(09:19:11 PM) patton: is preferable to have only names
(09:19:12 PM) ulf82: So the generic solution would be to allow layers or so in each package, right?
(09:19:16 PM) patton: like warrior.jog
(09:19:19 PM) patton: jpg
(09:19:19 PM) ulf82: well.
(09:19:35 PM) patton: well we can force another level
(09:19:35 PM) ulf82: you would still need to know that it is not just any warriro, but the one in the orc subdirectory.
(09:19:42 PM) patton: sure
(09:19:52 PM) patton: but you will add the subpackage
(09:19:59 PM) ulf82: I mean this information item needs to be extracted and given to the repository somehow.
(09:19:59 PM) patton: as enum or similar
(09:20:07 PM) patton: yes sure
(09:20:42 PM) patton: there is something i do not like in the repo right now
(09:20:59 PM) patton: we are in a spurous state
(09:21:04 PM) patton: spurious
(09:21:12 PM) patton: and this si not so good
(09:21:28 PM) patton: half parametric, half hardcoded
(09:22:11 PM) patton: on the oter hand having an enum for races is a ad thing too
(09:22:19 PM) patton: bad
(09:22:31 PM) ulf82: You could enforce a policy:
(09:22:48 PM) ulf82: Say, for armies, all data items are in a subdirectory with the name of the armyset.
(09:22:53 PM) patton: since when we would like to add another race is a problem
(09:23:10 PM) ulf82: And whenever you request a resource, you need to supply that it is an army, the armyset, and then the name of the army.
(09:23:29 PM) patton: so basically you add another layer
(09:23:32 PM) ulf82: From the point of view of the repository, you just give a resource name in multiple pieces.
(09:23:46 PM) patton: yes
(09:24:19 PM) patton: right now city levels cannot be implemented too :)
(09:24:45 PM) patton: you must play with pictures' name
(09:24:55 PM) patton: to obtain different pictures
(09:25:23 PM) ulf82: The generic problem I see here:
(09:25:36 PM) ulf82: You have all this context-dependent information.
(09:25:42 PM) ulf82: Different for different items.
(09:25:50 PM) ulf82: For armies, it is the armysetname and the army name,
(09:25:52 PM) patton: more a city must have a race
(09:26:00 PM) ulf82: for cities it is the level
(09:26:12 PM) patton: and race too
(09:26:19 PM) ulf82: at some point you need to piece it together to form a reasonable filename.
(09:26:21 PM) patton: also the "cityset"
(09:26:24 PM) patton: yes
(09:27:14 PM) patton: but all this data is parametric in the map objects
(09:27:16 PM) ulf82: The simple solution is just to treat every resource as containing an arbitrary number of buidling blocks, from which the repository forms the path name.
(09:27:29 PM) ulf82: Then the person who builds the data package needs to know and follow the convention.
(09:28:01 PM) ulf82: and of course, the code needs to query correctly. mmhhh...
(09:28:41 PM) ulf82: The more elaborate version would require you to centralize at least in the code the convention for each package.
(09:29:05 PM) ulf82: So if you want to get an army, you need to get a certain module which requires you to specify the army set and the army name.
(09:29:48 PM) patton: well right now the problem came out because Theodor wanted to "specialize" drawers
(09:30:17 PM) patton: but what we need is a single parametric Drawer that takes only a picture path
(09:30:33 PM) patton: and parameters are taken from map objects
(09:30:48 PM) patton: so city should have a level and a picture name in it
(09:31:05 PM) patton: so that the drawer can be created joining cityname+level
(09:31:11 PM) patton: ah and city race too
(09:31:29 PM) patton: so right now the work to be done is to add missing fields to map objects
(09:31:33 PM) ulf82: and then when querying the repository, you ask for a "city" picture and pass the city, and the repository will automatically extract everything of importance?
(09:31:52 PM) patton: like : race, picture name
(09:32:01 PM) patton: and specialize thing on each map onject
(09:32:07 PM) patton: yes
(09:32:10 PM) ulf82: I think I slowly warm up to the idea. Following very rough sketch:
(09:32:23 PM) ulf82: We ditch the package enum.
(09:32:45 PM) ulf82: Instead, a repository consists of a number of ResourceRetrievers (temporary name)
(09:33:05 PM) ulf82: You basically tell the repository "Get me the stuff for this object"
(09:33:25 PM) ulf82: and the repository looks up in its internal list of resource retrievers, who might be interested to deal with this object.
(09:33:26 PM) patton: exact
(09:33:39 PM) ulf82: the retrievers know the top level path and extract all the data
(09:33:43 PM) ulf82: from the object.
(09:33:45 PM) patton: each object must be filled with correct information
(09:34:06 PM) patton: doing that we will have a very easy code
(09:34:10 PM) patton: but almost general
(09:34:15 PM) ulf82: yes.
(09:34:34 PM) ulf82: Is this more or less blocking the drawing task?
(09:34:53 PM) patton: yes i blocked those tasks
(09:35:07 PM) patton: this si bloking
(09:35:10 PM) ulf82: I think the details will not be too hard to work out.
(09:35:15 PM) patton: is
(09:35:47 PM) ulf82: Since we use it everywhere, probably an acceptObject() function or so could be used to check if some retriever takes the object
(09:36:05 PM) ulf82: and you will need a RepositoryBuilder to set everything up.
(09:36:26 PM) ulf82: I might be overly optimistic, but ... two weeks?
(09:36:37 PM) patton: well we need an abstract class that will hold the basic fields
(09:36:49 PM) ulf82: Which basic fields?
(09:37:30 PM) patton: well it depends in what comes out
(09:37:30 PM) patton: do we already have mapentity yes?
(09:37:52 PM) ulf82: I would suggest that these Retriever classes just take an object and know what to do with it.
(09:38:02 PM) patton: package, resouce name or more
(09:38:08 PM) ulf82: Since different objects require simply completely different data.
(09:38:16 PM) ulf82: A city has no use for an armyset.
(09:38:22 PM) patton: so what would be a retriver?
(09:38:47 PM) ulf82: My temporary class from 9:32:45, that would take an object and look up the resource.
(09:39:19 PM) ulf82: temporary class name
(09:39:33 PM) patton: yes sure, i understood the idea but we do not have any formal definition yet
(09:39:59 PM) ulf82: Sure, it was only a sketch.
(09:40:04 PM) ulf82: Before we proceed here:
(09:40:11 PM) ulf82: How to continue?
(09:40:27 PM) ulf82: We can design it in-depth here. Or you can have another chat with Theodor & co.
(09:40:48 PM) ulf82: The former way might be slightly easier, the latter one more ... correct.
(09:40:52 PM) patton: mmm since this is not trivial is better to define it here
(09:41:25 PM) patton: i mean this is blocking but unrelated to theordor's and tomasz tasks
(09:41:50 PM) ulf82: Well, someone has to implement it; if this is blocking, I assume Theodor and Tomasz are pretty much free right now.
(09:42:11 PM) patton: i believe i will :)
(09:42:20 PM) ulf82: Ah, I understand. :)
(09:42:23 PM) patton: or i would assign to them
(09:42:39 PM) patton: but i would prefer to keep it working
(09:42:52 PM) patton: after that i would unblock those tasks
(09:42:54 PM) ulf82: Ok, then let's try to refine it before going bottom up.
(09:43:01 PM) patton: so that they can complete the coding
(09:43:28 PM) ulf82: 1. There is a DataRepositoryBuilder that assembles a working data repository (to be done last)
(09:43:48 PM) patton: yes
(09:44:03 PM) ulf82: 2. The data repository basically gets a list of helper objects to convert objects into resource names in the constructor
(09:44:29 PM) ulf82: 3. You can then give it an object, and it passes this around the helpers to get a resource name and load the resource.
(09:44:55 PM) ulf82: 4. The helpers themselves need to be implemented for each use-case (armies, cities etc.)
(09:45:32 PM) patton: yes
(09:45:44 PM) ulf82: 5. One thing not to forget in the end: We somehow need to be able to list resources of a certain category (scenarios)
(09:45:55 PM) ulf82: Sounds like a good project to try out branching. :)
(09:46:04 PM) patton: yes :)
(09:46:19 PM) patton: well point 5 is already implemented
(09:46:19 PM) ulf82: Did I forget anything obvious?
(09:46:30 PM) patton: i would not touch it right now if not needed
(09:46:42 PM) ulf82: Well, it is implemented _now_; it also needs to integrate into the new system.
(09:46:44 PM) patton: mmm i d not believe so
(09:46:53 PM) ulf82: ok.
(09:47:00 PM) ulf82: Then let's do the bottom-up design.
(09:47:04 PM) patton: we will see if it will break
(09:47:06 PM) ulf82: I guess we should start with the helpers.
(09:47:15 PM) patton: yes
(09:47:19 PM) ulf82: What name?
(09:47:31 PM) patton: pheraps Visitor is the correct name :)
(09:47:47 PM) ulf82: Referring to the visitor pattern?
(09:47:50 PM) patton: yes
(09:48:05 PM) patton: it takes a class and visit it and generate somethng (in this case a path)
(09:48:29 PM) ulf82: However, the purpose is not immediately obvious from the name.
(09:48:39 PM) patton: yes
(09:48:47 PM) ulf82: What fragments I coudl think of: Translate, Lookup, ...
(09:48:59 PM) ulf82: uhm...
(09:49:03 PM) patton: mmmm
(09:49:17 PM) patton: resourceFinder?
(09:49:25 PM) ulf82: sounds reasonable.
(09:49:38 PM) ulf82: Ok. So we have an interface ResourceFinder.
(09:49:46 PM) patton: so a resorceFinder will have a type?
(09:49:53 PM) patton: like picture
(09:49:53 PM) ulf82: you mean generic type?
(09:49:55 PM) patton: xml
(09:49:58 PM) patton: txt
(09:50:01 PM) patton: sound
(09:50:05 PM) patton: something like that?
(09:50:18 PM) ulf82: Depends.
(09:50:30 PM) patton: i am thinking about file extensions
(09:50:31 PM) ulf82: No, actually not.
(09:50:35 PM) ulf82: Because:
(09:50:39 PM) patton: for a picture we will have many extensions
(09:50:52 PM) ulf82: Imagine you have an army, then you could query different aspects of the army: its xml definition file, or its image.
(09:51:08 PM) patton: yes
(09:51:19 PM) ulf82: So the type of the resource should be handed over to the repository in any case, and maybe then forwarded to the finder as well.
(09:51:29 PM) patton: so we will have an Armyfinder?
(09:51:43 PM) patton: with hardcoded information in how to find n army?
(09:51:45 PM) ulf82: Yes.
(09:52:02 PM) ulf82: Including the package name (i.e., it will prepend "army" in front of everything else)
(09:52:06 PM) patton: ok so resorcefinder is the interface
(09:52:11 PM) ulf82: yes.
(09:52:24 PM) patton: for each object we will have a finder implementation
(09:52:29 PM) ulf82: yes.
(09:52:36 PM) ulf82: And I would give the interface two functions:
(09:52:40 PM) ulf82: acceptObject()
(09:52:45 PM) ulf82: and findResource();
(09:53:06 PM) ulf82: or assembleResource(), that is more appropriate.
(09:53:19 PM) ulf82: (it does not strictly find the resource, but just assembles the expected name)
(09:53:47 PM) patton: the accept methos will check for object type?
(09:53:59 PM) ulf82: they are not bound to it, but typically, yes.
(09:54:21 PM) patton: well i expect that an armyfinder will reject a village
(09:54:26 PM) ulf82: sure
(09:54:37 PM) patton: will accept only an object of army type
(09:54:43 PM) patton: ops unit type
(09:54:56 PM) ulf82: actually, it would be a UnitFinder, yes. :)
(09:55:07 PM) ulf82: Nomenclature is hard to change, it seems. :)
(09:55:12 PM) patton: since army will take the biggest unit picture :)
(09:55:36 PM) patton: (more powerful i mean)
(09:55:44 PM) ulf82: So, acceptObject(), assembleResource() is ok?
(09:56:08 PM) patton: mmm the second is not so correct to me
(09:56:26 PM) ulf82: getResourceName()/
(09:56:27 PM) ulf82: ?
(09:56:31 PM) patton: better
(09:56:53 PM) ulf82: What about calling the object ResourceNameFinder?
(09:56:56 PM) ulf82: interface
(09:57:03 PM) patton: ok
(09:57:16 PM) ulf82: ok.
(09:57:31 PM) ulf82: Then we would need implementations for the unit in any case...
(09:57:40 PM) patton: yes
(09:57:50 PM) ulf82: scenarios.
(09:57:57 PM) patton: city
(09:57:59 PM) ulf82: and sound items. They are actually a bit tricky.
(09:58:00 PM) patton: villages
(09:58:37 PM) ulf82: yes, I mean these others would be added, but some will be needed for backwards-compatibility right from the start.
(09:58:52 PM) ulf82: One second...
(09:58:57 PM) patton: yes
(10:00:12 PM) ulf82: Sounds need to be redesigned a bit, it seems.
(10:00:23 PM) ulf82: When you want to have a music piece, you basically only know its name.
(10:00:42 PM) ulf82: So this would have to be wrapped somehow to be interpretable in this workflow.
(10:00:45 PM) ulf82: code flow
(10:01:14 PM) ulf82: A similar issue is in ScenarioBuilder
(10:01:20 PM) patton: well a soundFinder can have hardcod all the ret
(10:01:22 PM) patton: rest
(10:01:39 PM) patton: do you think this is a discussion that can go in ML?
(10:01:50 PM) patton: pheraps more ideas can be welcome
(10:01:54 PM) ulf82: At that level of detail, no.
(10:02:18 PM) ulf82: If there is an almost finished concept, or if basic ideas are sought, the ML would be a good option.
(10:02:26 PM) ulf82: Otherwise, for hammering out the design, it is too slow.
(10:02:33 PM) ulf82: I would say.
(10:03:07 PM) patton: well what I see here is that we risk to broke everything
(10:03:13 PM) patton: break
(10:03:24 PM) ulf82: Sure, we do. :)
(10:03:56 PM) ulf82: But it looks as if this might indeed be a good topic for a smaller side project of 2-3 chats.
(10:04:21 PM) patton: mmm what is the smaller change we can do to achieve the goal without reinventing the wheel ?
(10:04:58 PM) ulf82: You mean some kind of "hack" that can be done properly later?
(10:05:00 PM) patton: honestly i do not remember the repository code so well i must see it again :)
(10:05:24 PM) patton: right now what we have is a repository interface
(10:05:32 PM) patton: and it cannot be changed
(10:05:47 PM) patton: since it is out compatibility layer
(10:05:51 PM) patton: our
(10:06:00 PM) ulf82: The simplest way would be to say in ResourceRepository.getStream() that a resource can be made up of more than one string.
(10:06:26 PM) ulf82: and then adapt the resource data.
(10:06:41 PM) ulf82: I mean, implement some kind of policy.
(10:06:57 PM) patton: it seems that we need to break the interface
(10:07:01 PM) ulf82: it does have the disadvantage that this policy would be scattered around the code base.
(10:07:02 PM) ulf82: Yes.
(10:07:06 PM) patton: the policy is not acceptable
(10:07:27 PM) ulf82: And it also seems that this should be done in a more stringent way.
(10:07:46 PM) patton: ok let's say we change the interface
(10:07:59 PM) patton: what will be the new repo interface?
(10:08:33 PM) ulf82: Mostly, getStream() would be replaced by a version where you supply an object instead of a string.
(10:09:01 PM) ulf82: Although, as mentioned above, the string version might also be useful at times.
(10:09:40 PM) patton: mmm yes
(10:10:02 PM) ulf82: However, this might also have some policies associated with it.
(10:10:16 PM) ulf82: For example, scenario definition files would reside in some directory with a standard name.
(10:10:31 PM) ulf82: Two thoughts:
(10:11:21 PM) ulf82: 1. We could make a hack that will be supplanted by a proper redesign of the resource repository. we already have the cornerstones how to have it.
(10:11:31 PM) patton: mmm right now we have 3 interface's method
(10:11:45 PM) ulf82: Usually we are rather short of non-blocking tasks, so this will definitely be done rather soon.
(10:12:06 PM) patton: InputStream getStream(ResourcePackage directory, String name, ResourceType type)
(10:12:07 PM) patton: throws FileNotFoundException, IllegalStateException;
(10:12:14 PM) ulf82: 2. Since the map canvas thing comes towards the end, you could take Tomislav and Tomasz with you on this side-task.
(10:12:33 PM) ulf82: Right now, various game setup things are blocking.
(10:12:35 PM) patton: well yes
(10:12:50 PM) ulf82: So you have at least a month before matters become pressing.
(10:13:05 PM) ulf82: I would accept any of the two options.
(10:13:37 PM) patton: to me point 1 is better so that we can think better to the redesign
(10:13:58 PM) ulf82: It is something that can easily blow up time-wise, yes.
(10:14:09 PM) patton: getStream(ResourcePackage directory, String name, ResourceType type)
(10:14:10 PM) ulf82: My two-chat estimate was already wrong. :)
(10:14:14 PM) patton: this is the current interface
(10:14:31 PM) patton: basically this will bocome somethign like
(10:14:57 PM) patton: getStream(ResourcePackage directory, objectInterface object);
(10:15:19 PM) patton: he other one can be left as it is
(10:15:20 PM) patton: getResourceNames(ResourcePackage directory)
(10:15:31 PM) patton: mmm no
(10:15:36 PM) ulf82: and objectInterface would be what?
(10:15:39 PM) patton: me ween to add the layers too ....
(10:16:04 PM) patton: well objectInterface would be something like a superclass
(10:16:24 PM) patton: since we pass various typesof objects
(10:16:31 PM) patton: like army
(10:16:33 PM) patton: city
(10:16:37 PM) ulf82: And then you basically say UnitObject etc.
(10:16:43 PM) ulf82: And this you have to fill by hand?
(10:17:04 PM) patton: well this is filled by client with server data
(10:17:39 PM) ulf82: when you want to draw something, this would only happen on the client side, right?
(10:17:45 PM) patton: yes
(10:18:16 PM) ulf82: and during this drawing you would assemble and pass the ObjectInterfaces to the repository to get the streams?
(10:18:53 PM) patton: well we do not asseble the object since it is already there (for example a city)
(10:18:59 PM) patton: or an army
(10:19:03 PM) patton: or a vlage
(10:19:07 PM) patton: village
(10:19:14 PM) patton: or some other map object
(10:19:26 PM) ulf82: Now I am slightly confused. Are we talking about what is going to be implemented quickly or finally?
(10:19:47 PM) patton: no no i was always talking about the refactoring
(10:20:00 PM) patton: right now we can just decide to pass a composite string
(10:20:08 PM) ulf82: Ah, ok.
(10:20:14 PM) ulf82: Yes.
(10:20:16 PM) patton: like /orc/warrior
(10:20:19 PM) ulf82: I am just assembling a memo.
(10:20:48 PM) patton: but i am convincing that this rewrite will be not easy at all
(10:21:05 PM) patton: since we have many different situation
(10:21:17 PM) patton: situations where we will need to find aresource
(10:21:29 PM) patton: 1) pictures
(10:21:32 PM) patton: 2) xml
(10:21:33 PM) ulf82: sure.
(10:21:38 PM) patton: 3) sounds
(10:21:48 PM) patton: 4) oter things
(10:21:55 PM) ulf82: Well, the type can be done by adding a type. When you want to get a resource, you always know from the context what type of thing you want to have.
(10:21:57 PM) patton: right now we have a general system
(10:22:03 PM) ulf82: adding a type information.
(10:22:23 PM) ulf82: Let's postpone this to the actual redesign.
(10:22:31 PM) patton: we have a chicken- egg problem
(10:23:01 PM) patton: who load the information and passes them to the client? and how?
(10:23:28 PM) patton: which object can you pass to the server repo to load a scenario?
(10:23:41 PM) patton: you won't have it
(10:24:03 PM) ulf82: basically a string that the server has to interpret properly. This can be figured out, though it is non-trivial, I admit.
(10:24:21 PM) patton: so pheraps is better to add only a new layer
(10:24:46 PM) patton: resource package, sublayer, resource name, resource type
(10:25:00 PM) patton: we add a new parameter and that's it
(10:25:41 PM) patton: so /city/orc/city_level1
(10:25:42 PM) ulf82: I would suggest at some point to add a design task to study the feasability.
(10:25:51 PM) patton: yes
(10:27:08 PM) ulf82: typing the memo...
(10:27:18 PM) patton: ok
(10:27:21 PM) patton: brb
(10:28:39 PM) ulf82: task 215 in the backlog (under "Misc tasks")
(10:32:04 PM) patton: ok
(10:32:15 PM) patton: another prob
(10:32:20 PM) ulf82: yes?
(10:32:51 PM) patton: adding the laye to the interface is problematic since you need to invent something to handle the case of non exsistent sublayer
(10:33:11 PM) patton: like scenario/scenariofile.xml
(10:33:44 PM) patton: this is thoughter that i thought
(10:33:47 PM) ulf82: when we are at temporary solutions: add a function that takes the sublayer...
(10:34:07 PM) ulf82: or require it always.
(10:34:28 PM) patton: well the fist is better since it does not brackreto-compatibility
(10:34:32 PM) patton: first
(10:34:37 PM) ulf82: ok
(10:34:47 PM) patton: we add a newer getresource
(10:34:54 PM) ulf82: ok
(10:34:55 PM) patton: that takes alsothe sublayer
(10:35:08 PM) patton: for other cases we stick to the old interface
(10:35:12 PM) ulf82: yes
(10:35:17 PM) patton: ok then
(10:35:27 PM) patton: so i would add this piece of code
(10:35:35 PM) ulf82: ok.
(10:35:37 PM) patton: so that task 177 and 187 can be completed
(10:35:51 PM) patton: we will talk again resource repo refactoring later
(10:35:52 PM) ulf82: And regarding my Integration test problem, also a few questions.
(10:35:57 PM) patton: sure
(10:36:29 PM) ulf82: What I would do is basically reimplementing FreelordsServer/ClientBuilder for test cases.
(10:36:41 PM) ulf82: Where you can somehow conveniently define which room you want to have for the server.
(10:36:47 PM) ulf82: and then make the integration test.
(10:37:40 PM) patton: mmm a lot of work
(10:37:43 PM) ulf82: Actually, the client builder seems to not even require a reimplementaion, it is fine the way it is.
(10:37:57 PM) ulf82: Well, most of the code actually sets up the various rooms in the server builder.
(10:38:02 PM) ulf82: This could be simplified.
(10:38:13 PM) ulf82: But we will have a few other such integration tests coming up soon.
(10:38:20 PM) ulf82: So there should be a solution.
(10:38:37 PM) patton: well so the problem is server related right?
(10:38:52 PM) ulf82: Essentially yes.
(10:39:14 PM) ulf82: I want to set the main room, but this is (correctly) forbidden unless the server is constructed.
(10:39:43 PM) patton: so pheraps we can refactor the server code builder to be more parametrical
(10:40:41 PM) patton: i mean
(10:40:53 PM) patton: we can tell the server which room to start with
(10:41:01 PM) ulf82: a simple way would be to require the main room in the builder, and outsource the room setup into a separate class?
(10:41:37 PM) patton: all roomsmust be created before create the server?
(10:41:50 PM) patton: if yes then we can outsource room building
(10:41:57 PM) patton: and pass themto the server builder
(10:42:03 PM) ulf82: Those that require server data will be created on the fly (game rooms, configuration rooms)
(10:42:14 PM) ulf82: ok, then I will refactor the code in this way.
(10:42:54 PM) ulf82: have a ServerRoomSetup that returns the main room, and pass it to the FreelordsServerBuilder.
(10:43:06 PM) patton: after that we set the default server room to start with
(10:43:18 PM) patton: yes
(10:43:25 PM) ulf82: well, the default server room is the one at the top of the tree. :)
(10:43:32 PM) patton: so you can make tests
(10:43:38 PM) patton: with different main rooms
(10:43:38 PM) patton: and you do not need to rewrite anything
(10:43:49 PM) ulf82: test the server builder, yes.
(10:43:54 PM) patton: but use the production code
(10:44:13 PM) ulf82: that is the best solution, indeed.
(10:44:23 PM) patton: ok then one problem solved :)
(10:44:27 PM) patton: at least
(10:44:30 PM) ulf82: yes.
(10:44:35 PM) ulf82: Ok.
(10:44:41 PM) ulf82: I think this dragged on long enough.
(10:44:48 PM) patton: ok
(10:45:16 PM) patton: e will chat again after coding these little refactoring
(10:45:19 PM) patton: we
(10:45:28 PM) ulf82: we can.
(10:45:49 PM) ulf82: That would probably be around of after Easter.
(10:45:54 PM) ulf82: or
(10:45:59 PM) patton: yes sure
(10:46:12 PM) patton: this weekend to me is off :)
(10:46:12 PM) ulf82: Just remind me early enough. :)
(10:46:42 PM) ulf82: My relatives are busy, but my son will require a certain constant oversight.
(10:46:48 PM) patton: ok then we will keep in touch by mail
(10:46:51 PM) ulf82: yes.
(10:46:56 PM) patton: i have 2 :)
(10:47:10 PM) patton: anyway
(10:47:12 PM) ulf82: Do they also go straight for the laptop as soon as they enter the room?
(10:47:12 PM) patton: ok
(10:47:21 PM) patton: as usual :)
(10:47:37 PM) patton: to the laptop, to the mobile phone, to everything they can broke
(10:47:58 PM) ulf82: remote controls are also utterly fascinating.
(10:48:05 PM) patton: technology is a sort of catalizer for children
(10:48:28 PM) patton: to the table too :)
(10:48:31 PM) patton: tablet
(10:48:50 PM) ulf82: Right, my ebook I can also no longer use in his presence.
(10:49:07 PM) ulf82: anyway.
(10:49:11 PM) ulf82: Enoguh complaints. :)
(10:49:15 PM) patton: :)
(10:49:19 PM) patton: ok then
(10:49:28 PM) ulf82: yes, have a happy easter.
(10:49:35 PM) patton: i would not add a task about this new interface
(10:49:41 PM) patton: i just do it and commit
(10:49:48 PM) patton: it should be straightforward
(10:49:50 PM) ulf82: you mean the lightweight change?
(10:49:53 PM) patton: yes
(10:49:57 PM) ulf82: yes.
(10:50:00 PM) ulf82: fine with me.
(10:50:12 PM) patton: ok then see you later and happy easter
(10:50:23 PM) ulf82: see you.
(10:50:31 PM) patton: ah can you publish the chat/
(10:50:33 PM) patton: ?
(10:50:34 PM) ulf82: sure
(10:50:37 PM) ulf82: no problem
(10:50:37 PM) patton: ok
(10:50:39 PM) ulf82: bye
(10:50:42 PM) patton: bye