(19:42:58) MingChen: ok
(19:44:05) MW__: I have about 13 emails from that mail list that I need to read and catch up on
(19:46:59) dalien: hmm looks like Logout() from Clientview.Packethandlers needs to have part of its code pushed into the Clientview - seems some redundant stuff to me...
(19:48:14) MW__: most of that code, is very likely to be hang overs from trunk, the log out code really hasn't been done yet.
(19:48:45) dalien: ok, i will play with it and see what i can do - since having the "announce the presence" also implies "announce leaving" :)
(19:48:54) dalien: and without the actual leaving hard to announce it :)
(19:49:38) MW__: btw you have noticed that ClientView.PacketHandlers.cs is part of ClientView, its a partial class spread over a few files, basically I did it like that as it was getting so big and hard to manage while it was being rewrote
(19:50:23) dalien: yup. From what I see I need to cut out some code in the Logout and replace it with a call to KillClient
(19:51:05) Darok [~chatzilla@81.184.133.234.dyn.user.ono.com] entered the room.
(19:51:05) MW__: yeah, although I would check what KillClient() is actually doing, and check its doing things right
(19:51:18) dalien: it is the same functions, from what I compared
(19:51:25) MW__: ah
(19:51:31) Darok: Hi again
(19:51:34) dalien: seems like copypaste
(19:51:39) MW__: hey Darok
(19:52:34) MW__: we want to call IWorld.RemoveClient(LLUUID agentID) as well (don't think that is being called)
(19:52:56) dalien: yes - it seems currently the avatar gets stuck in the world...
(19:53:22) dalien: hmm although that seems to be called in the KillClient... let me check if it actually works :)
(19:54:57) dalien: hmm right - I'll need to track that down
(19:55:23) dalien: btw - if I have a timer in the object which is started - if i dispose of the object - the timer would stop ? or i need to stop it explicitly ?
(19:55:26) MW__: well from a quick look , a lot of what is in KillClient should be moved to scene anyway , the KillObjectPacket kill packet should be done from scene (although the actual packet creation should be a method in IClientAPI) , but we should be doing the call from ClientView
(19:55:48) MW__: thats we shouldn't be doing the call from ClientView
(19:56:26) MW__: dalien, not 100% certain
(19:58:10) dalien: ok i will check.. so basically the removal of the client from the scene should be done from the call in the scene iterating over all avs to send the kill packet
(19:58:24) dalien: the logout handler still stays within the ClientView though ?
(19:59:30) dbm_ is now known as danx0r
(19:59:35) MingChen: set proposal on the mailing list
(20:00:45) ***MingChen yays as a simple product I made is now ranked #33 on sales on slexchange
(20:04:44) MW__: dalien, yeah, basically anything scene related (like removing the avatar ) should be called from in scene, while the rest can be in ClientView
(20:05:35) dalien: ok. and how about interacting with the packet manager, etc. ? I currently create the timer within the clientview..
(20:06:16) dalien: then the failure to keepalive should call scene which should remove the object on high level - but who would take care of the cleanup with the packetmanager ?
(20:06:33) dalien: (I'm still grasping the infra, so forgive me the stupid questions :)
(20:06:54) MingChen: brb, about 15 mins
(20:07:39) MW__: I think ClientView should deal with cleanup, but as you said call Scene to remove the avatar, basically scene shouldn't have any low level network stuff in it (although currently it still has bits here and there)
(20:08:03) MW__: the idea is that other ClientView versions could be wrote that use different protocols
(20:08:35) dalien: ok. btw - seems like there is a pattern "for all the avs in the scene do "blah"" - does the language provide a means to abstract that out (iterator?), or is it ok to duplicate the cycle code ?
(20:08:37) MW__: we aren't at that stage yet as things are still too tightly coupled, but thats the goal
(20:09:38) MW__: well foreach( ObjectType t in Whatever) is a iterator
(20:10:08) dalien: ok
(20:12:29) MW__: so foreach (ScenePresence avatar in Avatars.Values){ avatar.dowhatever() } (unless I missunderstood the question)
(20:12:40) dalien: aha i think that's it.
(20:17:12) MW__: hmm, really need to spend less time talking in here and more time working, haven't got hardly anything done to opensim tonight
(20:20:09) dalien: hm sorry :( i will stop asking and start digging more myself. thanks for the clarifications..
(20:23:13) MW__: no I didn't mean it like that
(20:23:25) dalien: np
(20:24:11) MW__: just meant that once again I was going to get so much done, and haven't got half of it done, so was annoyed with myself
(20:24:21) dalien: ah ok :)
(20:24:32) dalien: sorry for distracting you anyway
(20:25:06) ILLGibson left the room (quit: Read error: Operation timed out).
(20:25:39) MW__: well don't be , if you have questions, ask them
(20:26:04) dalien: k :) now i am trying to code up what we discussed
(20:26:44) dalien: will have KillFromScene() method for the scenepresence that removes the av from the scene + notifies the others via calls in ClientAPI.
(20:27:21) MW__: sounds good
(20:27:27) MingChen: back
(20:28:01) GibsonWil [~poshaughn@207-237-227-215.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com] entered the room.
(20:37:12) Magian left the room (quit: Bye all, see you next time).
(20:50:26) dalien: naming convention, what is right: AgentID, or agentId ?
(20:50:51) AdamZaius: agentID?
(20:50:57) dalien: k
(20:51:08) AdamZaius: We really need to go through and fix up some of the names.
(20:51:12) AdamZaius: I spotted some bad offendors earlier today.
(20:55:09) Magian [user@d54C645CF.access.telenet.be] entered the room.
(21:22:36) Darok left the room (quit: Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502]).
(21:31:38) dalien: hmm ok the presence seems to work..
(21:33:35) makomk: dalien: The real client does respond to StartPingCheck (and the real grid server sends it), judging from the SLProxy log I'm looking at
(21:35:25) lbsa71 [~a@c-28c8e253.227-2-64736c12.cust.bredbandsbolaget.se] entered the room.
(21:35:56) mode (+o lbsa71) by DollyDNA
(21:38:34) dalien: ah cool
(21:38:38) dalien: so then my patch should be fine
(21:39:11) dalien: i am sending the ping if there were no packets since the last timer (currently doing every second, the real SL does more frequently, but i think this is overkill on their side)
(21:39:32) dalien: no packets = no packets different from viewerupdate.
(21:41:20) dalien: also, I've added the circuit# for printing the in/out packets
(21:41:30) dalien: with multiple clients this seem to make debugging bit easier
(21:43:26) lbsa71: MW__ AdamZaius you there?
(21:43:34) AdamZaius: Yes.
(21:43:36) AdamZaius: Barely.
(21:44:08) lbsa71: dalien how's the open source anims going?
(21:44:27) lbsa71: AdamZaius can we incorporate animations.xml in sugilite?
(21:45:10) dalien: lbsa: posted the blog entry, and a friend of mine with high-traffic blog posted on hers - did not check yet... I think will take some time before it spreads :)
(21:45:33) AdamZaius: lbsa71, we should be - just be aware that the XML file itself is under a creative commons license since I poached the UUIDs from viewerart.ini
(21:45:42) AdamZaius: The animations themsleves are hard coded into the client.
(21:46:10) dalien: hmm so any file we create and put the UUIDs into, would automatically become CC-licensed ?
(21:46:23) AdamZaius: Well if you copy them, yes.
(21:46:35) dalien: not if you type them in by hand ? :)
(21:46:35) AdamZaius: If you sniff them out over the wire and deduce them from that, I'm not sure.
(21:46:38) dalien: aah
(21:46:51) dalien: then probably better with external anims...
(21:46:58) dalien: but this poses another prob of downloading them, etc.
(21:46:58) AdamZaius: The XML file is fine, it's not like the GPL where it infects everything it's linked to, it's just a data file.
(21:47:05) AdamZaius: No, they are packaged with the viewer.
(21:47:07) lbsa71: Well, we can incorporate it now and exclude it when we get our own open source variants.
(21:47:19) AdamZaius: The SL client has a file called staticcontent.idc which includes em.
(21:47:22) lbsa71: I take that as a 'yes' and reappply daliens pathc
(21:47:23) AdamZaius: So we dont need to send them from the sim.
(21:47:32) AdamZaius: Yeah
(21:47:48) AdamZaius: once we have our own open source anims, we can ditch the LL parts of that file and replace them with out own, bringing it back to a more friendly license.
(21:48:06) dalien: i have the "presence" initial patch almost ready - anyone will be here in some 60+ minutes to review ?
(21:48:18) lbsa71: I will probably be here
(21:48:29) AdamZaius: I wont, heading to bed.
(21:48:35) AdamZaius: But I can apply stuff in the morning.
(21:48:39) dalien: cool. it deals with the inability of the agents to see each other + disconnecting the dead clients.
(21:49:06) AdamZaius: libsl stuff too?
(21:49:11) dalien: yes
(21:49:14) dalien: although, one thing
(21:49:18) dalien: libsl stuff does not become visible
(21:49:20) lbsa71: I just have to boast; I have my office in very strange and quaint office 'collective', the main room is full of old furniture (like cinema seats and stuff) and has a aprty grade PA system;
(21:49:23) dalien: until it sends the "appearance" command
(21:49:52) lbsa71: right now I'm sitting in a red satin couch, all alone, listening to trance on club grade speaker and amplifiers. :D
(21:49:58) AdamZaius: dalien, probably best that way.
(21:50:00) dalien: not sure whether it is the right thing to do - to notify the others when we are sending the appearance. maybe we should do it once more somewhere earlier in the cycle ?
(21:50:11) AdamZaius: I'd rather we go nothing -> av, rather than nothing -> ruth -> av
(21:50:20) dalien: in the previous version of opensim the libsl appeared in a "borg-like" variant with funny wooden head :)
(21:50:25) AdamZaius: Normally there's that ruth step involved.
(21:50:35) AdamZaius: On the LL sims, but I think it's a waste of bandwidth really.
(21:50:45) dalien: one concern is that then someone could snoop
(21:50:47) AdamZaius: No point sending it down if it's only going to stick for half a second.
(21:50:49) dalien: without being noticed.
(21:51:05) AdamZaius: Well, should still appear on the minimap and in the agents list on the sim.
(21:51:23) AdamZaius: Plus, if you want private you can just firewall your sim.
(21:51:27) AdamZaius: privacy*
(21:51:32) dalien: good point :)
(21:51:54) lbsa71: dalien is the animations.xml supposed to be in the same place in sugilite as it's in trunk?
(21:52:02) dalien: lbsa: yes. bin/data/
(21:52:32) dalien: you can grep the diff - the path is hardcoded there. probably in the future we'd hook this up to an inventory server or something...
(21:52:43) lbsa71: ah, easier to just ask
(21:52:50) dalien: such that the "animation overrides" could be just a profile setting, and would not require to wear an extra script :)
(21:53:08) dalien: especially the girls will definitely love that feature :)
(21:53:43) lbsa71: Hell yeah; the animations should all be dynamic.
(21:53:54) lbsa71: That 'override' shit should just go.
(21:53:57) dalien: yup.
(21:54:39) dalien: and i will definitely blog about that :)
(21:55:03) AdamZaius: Be cool to be able to drag & drop preffered anims into a slot or something.
(21:55:13) AdamZaius: Anyway, I'm going to go to sleep, `night all.
(21:55:17) dalien: nite Adam
(21:55:22) lbsa71: AdamZaius nightie - night!
(21:56:24) CIA-1: opensim: lbsa71 Sugilite * r1206 / (5 files in 5 dirs): Re-applied dalien patch (#175) and included bin\data with avataranimations.xml
(21:57:20) dalien: hmm i am wondering where to put the stuff remaining from KillClient...
(21:57:53) dalien: in my code currently it looks like this: http://pastebin.ca/611137
(21:59:06) dalien: I tortured MW on the architecture, and removed most of the stuff from it (the sending of the kill packets is done by clientapi from sceneview cycling through all avs)
(21:59:40) lbsa71: Yeah; all packet serializing and deserializing should be done by the clientview.
(22:00:31) dalien: that's done. but the remainder are infra operations... disconnecting from network server, etc.
(22:00:44) dalien: would it be still best done in the m_world.RemoveClient(this.AgentId); ?
(22:00:52) lbsa71: Where is KillClient residing?
(22:00:59) dalien: in clientview
(22:01:19) lbsa71: So, why not call it Close() or something?
(22:02:06) lbsa71: Hmmm... the m_clientThreads should really really have been encapsulated in a ClientManager class
(22:02:28) dalien: hmm is it something that exists already or another big refactor needed ? :)
(22:02:33) lbsa71: The ClientManager should have had an Remove() that would do Close() on the clientview.
(22:02:41) lbsa71: I think you got your answer there.
(22:03:19) dalien: hmm looks like ClientManager does not exist yet...
(22:03:38) lbsa71: Well, I don't know exactly how 'big' it would be, but yeah; that thing with sending an ref to a dictionary like that is reeeealllyy itching all our refactoring itches.
(22:03:49) lbsa71: It's a blotch of old
(22:04:26) lbsa71: So, if you want to make us happy, introduce a class that manages that dictionary by exposing customized methods instead of the whole dictionary.
(22:04:45) dalien: i'm thinking - maybe you take a look at the patch, we commit it, then you create a dummy clientmanager class, and i go and refactor it ? (or tell me how to do it - i am a noob with C# :)
(22:05:01) lbsa71: Hmmm... what environment are you in?
(22:05:12) lbsa71: vs2005?
(22:05:23) dalien: vi + cscope :)
(22:05:29) lbsa71: iiik!
(22:05:32) lbsa71: oh well.
(22:05:33) dalien: (although cscope is not the most optimal tool for this :)
(22:06:03) dalien: btw - this stuff in killclient already exists
(22:06:14) lbsa71: Ok.
(22:06:27) dalien: so maybe we do it step by step - I show the full patch, you take a look, and then i go on with refactoring the clientmanager ?
(22:06:35) lbsa71: Well, I can introduce a ClientManager actually; I don't think I'm gonna get much more work done.
(22:06:40) lbsa71: Getting at it. Stay Tuned.
(22:06:43) dalien: cool!
(22:08:29) lbsa71: So, where shall I put it, you think?
(22:08:52) dalien: ugh. no clue - like i said i am still grasping the architecture...
(22:09:19) dalien: but thinking of it... clientmanager is a property of... ?
(22:09:55) lmmzafk [~x@wsip-68-14-211-43.ph.ph.cox.net] entered the room.
(22:10:20) lbsa71: Well, the IClientAPI is defined in .Framework, so best to keep it close.
(22:11:29) dalien: hmm otoh...
(22:11:43) dalien: is it not the clientapi that is already supposed to be doing this ?
(22:12:02) dalien: since it deals with all the lowlevel operations... and managing the client is close to that
(22:13:27) lbsa71: Well, it's quite easy to move it.
(22:13:47) lbsa71: Right now I just want to encapsule it, so we have something to add methods to.
(22:14:12) dalien: ah ok. so then it would be a property of the IClientAPI then ?
(22:15:01) dalien: (and have the backref to the clientAPI?)
(22:15:11) lbsa71: Umm... no, not really?
(22:15:33) lbsa71: Maybe I misunderstand you; but the IClientAPI is the core interface for one client
(22:16:03) lbsa71: So, this 'manager' would ideally be the one responsible for, for example, broadcasting to all clients
(22:16:18) dalien: hmm isnt it what the sceneview is already doing ?
(22:16:44) lbsa71: Quite probably, but the point is, it shouldn't
(22:16:54) lbsa71: It should ask the manager to.
(22:17:10) dalien: hmm... let me take a look at the sceneview - what does it do now
(22:17:26) lbsa71: If it is, the only reason is because there has been no manager, just a generic dictionary
(22:17:45) dalien: OpenSim/Region/Environment/Scenes/ScenePresence.cs - thats the file i was talking about
(22:19:13) dalien: then i might not be sure what the ScenePresence is supposed to do... maybe we should put up a wiki page somewhere, describing the architectural view
(22:19:48) lbsa71: Yup. That's quite backwards; letting the representation of one clients prescense directly call all others by iteration.
(22:19:59) lbsa71: That... would be a good idea. ;)
(22:20:11) lbsa71: I think some poor bastard has already tried to do that.
(22:20:29) lbsa71: The ScenePrescense is the avatar or the childagent.
(22:20:58) dalien: tried to document it ? any idea of the page name ?
(22:21:08) lbsa71: The representation of an agent regardless of whence the agent is on the scene or not.
(22:21:26) lbsa71: Hmm. No.. I'm not even sure it made it into the wiki.
(22:21:51) dalien: hmm ok, how about I start with the root page "OpenSim_Architecture" - and we dump the stuff there
(22:22:00) dalien: and once it grows, we move it on childpages
(22:22:16) dalien: since i think if the # of developers would grow (and it should grow, imho), we would need some governance.
(22:23:31) lbsa71: Of course, you are right; but I must warn you that architecture changes by the hour here.
(22:23:54) lbsa71: None of us here have ever done a general 3d application platform before.
(22:24:03) lbsa71: :D
(22:24:05) dalien: hehe me neither :D
(22:24:14) dalien: but at least would be interesting to capture *something* :)
(22:24:20) lbsa71: So, I would suggest you learn by coding
(22:24:27) lbsa71: And asking stupid questions.
(22:24:42) lbsa71: :)
(22:24:43) dalien: hmm ok :)
(22:25:03) dalien: I think I will still create that page though, if only for myself even :)
(22:33:48) dalien: I will create a ticket for the "presence" issue - care to take a look at it ?
(22:33:52) lmmzafk left the room (quit: ).
(22:33:56) dalien: (i mean at the patch)
(22:34:02) lbsa71: Yeah; just have to finish the manager first.
(22:34:15) dalien: k!
(22:37:06) lbsa71: dalien you good with delegates?
(22:37:25) dalien: hmm i am reverse-hacking C# - mostly by example :)
(22:37:54) dalien: usually code in C/ruby whenever I need
(22:38:25) lbsa71: Okay; delegates is type-safe managed method pointers.
(22:38:39) dalien: hmm ok.
(22:38:46) lbsa71: So, if you see something passing a method name as parameter, it's a delegate.
(22:38:52) dalien: ah cool.
(22:39:04) lbsa71: We make heavy use of it, because it lets you take some really nice shortcuts.
(22:39:16) dalien: well, basically it is akin to closures a little bit
(22:39:24) dalien: hm well, they are closures i think :)
(22:39:51) lbsa71: Like, for example, the ClientManager now has a 'ForEach( delegate )' that iterates over the private dictionary and executes the passed delegate.
(22:39:58) lbsa71: Yup. Closures.
(22:40:00) dalien: cool, indeed.
(22:40:15) dalien: ok it is a good programming concept - something i really love about ruby. so i am reasonably ok with them :)
(22:40:24) dalien: submitted #177 for the presence stuff
(22:40:52) lmmzafk [~x@wsip-68-14-211-43.ph.ph.cox.net] entered the room.
(22:41:05) lbsa71: Now, the reeeeally cool and dangerous feature is that c# creates a meta-class that the delegate uses as 'this'; the meta class contains pointers to all the referenced variables in the CALLING LOCAL SCOPE
(22:41:22) lbsa71: which means you can referernce local vars outside of the closure.
(22:41:38) dalien: hmmm interesting...
(22:42:00) dalien: so you have piece of code { my localvar; call(delegate) }
(22:42:01) lbsa71: It's effing dangerous, but again, opens up for convenient shortcuts.
(22:42:12) dalien: and within the delegate, you can reference "localvar" ?
(22:42:23) lbsa71: yup.
(22:42:37) lbsa71: local to the method
(22:42:43) dalien: ugh. but i assume you somehow need to say within the delegate "this is the variable in the calling scope" ?
(22:42:54) lbsa71: Nope; that's inferred.
(22:43:08) lbsa71: It's called 'anonymous delegates'.
(22:43:20) lbsa71: I'm gonna commit some examples now. ;)
(22:43:28) dalien: aaah, where you directly specify the block of code within the call, right ?
(22:44:01) lbsa71: yup.
(22:44:13) dalien: aha, i think i saw that somewhere in the code. nice - same as in ruby :)
(22:44:15) lbsa71: C# for teh win.
(22:44:20) lbsa71: I loves it.
(22:44:43) lbsa71: ruby is nice too.
(22:45:09) dalien: and the best is they are very similar in syntax
(22:45:09) lbsa71: But c# she my lady.
(22:45:25) dalien: for the dummygrid i copypasted pieces from the C# code with very little changes :)
(22:45:29) lbsa71: Well, c descendants...
(22:45:39) MW__ left the room (quit: Ping timeout: 318 seconds).
(22:45:44) lbsa71: :'(
(22:45:51) lbsa71: baj baj MW__
(22:46:12) dalien: (even though it is quick and veeeery ugly hack - but now i am launching opensim in grid mode all the time.
(22:46:41) lbsa71: that's good, because I always work in sandbox
(22:46:51) dalien: so we have better testing coverage :)
(22:46:52) lbsa71: I'm waiting for an unified interface
(22:46:56) dalien: although we discussed that
(22:46:58) dalien: today
(22:47:07) dalien: basically the idea is that region manager would be 2-tier
(22:47:10) dalien: MW's idea
(22:47:40) dalien: local one would take care of the regions running on the same computer (and he claims to be able to do that without the TCP/IP)
(22:48:01) dalien: then if it is in "grid" mode and it does not find the stuff - it would talk to external grid server
(22:48:08) dalien: in sandbox it would bail out.
(22:48:37) dalien: so it would provide the performance benefit for the local scenarios, and also allow gradual development of the interface to gridserver.
(22:49:00) dalien: I think MingChen was going to send a mail to the list describing the gory details of the discussion :)
(22:49:11) MingChen: I did
(22:49:18) dalien: cool! :) i did not look at it yet
(22:50:46) dalien: when/if the presence patch in #177 goes in, I will start digging into the texture crash
(22:51:05) dalien: so that eventually we could connect the libsecondlife testclient (even if with my dummygrid stuff)
(22:51:18) dalien: that should allow to write some interesting load-testing tools.
(22:51:41) dalien: connect 200+ avs and let them wander around :)
(22:55:50) lbsa71: Ummm... there is a libsl test client for opensim.
(22:55:55) lbsa71: I think MingChen wrote it.
(22:56:17) MingChen: its somewhere in the svn
(22:56:19) MingChen: one sec
(22:56:51) lbsa71: I just replied to the proposal
(22:58:19) dalien: hmm so you dislike the http ? :)
(22:58:47) dalien: i'm just thinking that the division between the "sandbox" and "grid" is a bit artificial.
(22:59:08) dalien: the main difference is the grid-related operations.
(22:59:43) dalien: so essentially all that involves the gridserver. (I did not look at that part of the code but MW was very adamant to do the stuff locally)
(22:59:54) lbsa71: Well, quite a lot changes if you don't have to be grid-aware.
(23:00:10) lbsa71: So Am I. Adamant. About locality.
(23:00:49) dalien: right. i am more worried about having the possibility to have the authentication / asset rep / inventory rep detachable
(23:00:54) MingChen: I think the big problem was the grid server speed in standalone mode, and that was solved with the two-tier gridserver idea
(23:01:19) CIA-1: opensim: lbsa71 Sugilite * r1207 / (38 files in 38 dirs): * Ignored all those autogenned build files
(23:01:37) dalien: yup. as far as i understood that was the case.
(23:01:41) lbsa71: Well, as I stated, I'm not gonna get obstinate about it.
(23:02:09) lbsa71: I just, as I stated, don't see why we have to go up into the comm layer.
(23:02:23) dalien: i was (and I think we are with MingChen on it) that having for the "less critical" services to always go through the comm layer would prevent to have two copies of the code
(23:02:27) lbsa71: Good interfaces would let us crorr-wire it.
(23:02:53) dalien: so you are always sure that the opensim part works - and that the builtin servers work too.
(23:02:53) dalien: :)
(23:03:00) lbsa71: Yes.
(23:03:11) lbsa71: That was why I once suggested it to MW.
(23:03:32) dalien: otherwise you would need to implement local servers + remoted servers classes. = code duplication
(23:03:36) CIA-1: opensim: lbsa71 Sugilite * r1208 /OpenSim/ (7 files in 4 dirs): * Introduced ClientManager for great justice.
(23:04:09) dalien: woot! :)
(23:04:42) lbsa71: Well; if there was a shared set of interfaces, the grid servers would implement them extensibly, but in snadbox all of them would be implemented by one single class, forwarding requests internally.
(23:05:12) dalien: you still need to have two copies of the interfaces - for sandbox and for the grid
(23:05:35) dalien: hence any changes there (which is not so infrequent ? :) would require to change in at least two places
(23:06:03) dalien: I'd think at least at the initial stage forcing to always use the network layer is a good thing
(23:06:41) dalien: and then for the performance reasons (once the dust settles, somewhere in the future), the local classes might be written which would avoid the tcp over 127.0.0.1
(23:09:48) lbsa71: Uh, no, why would you have to have two copies?
(23:10:22) dalien: one implementation to directly wire the classes, and one to wire them over the HTTP + the server side to wire them via HTTP ?
(23:10:29) dalien: so in fact it is even 1+ (1+1) ?
(23:10:41) lbsa71: Yes, but that's two different classes, not copies of interfaces.
(23:11:01) dalien: yes. but imagine you change the "local" interface
(23:11:19) dalien: by default the "remote" interface is broken until you also bring it to sync. boring, imho :)
(23:11:25) lbsa71: And, if there's four interfaces, there would be four interfaces, four grid implementations and one sandbox implementation
(23:12:04) lbsa71: You can't change the 'local' interface without changing the 'grid' interface since they both share the same interface?
(23:12:22) lbsa71: Or, are you talking about the implementations getting out of synch with the interfaces?
(23:12:46) lbsa71: Then the 'other' solution will not build, and we will have a build failure on our ccnet build server.
(23:12:55) dalien: hmm i think my lack of terminology sucks :) let me try to explain
(23:13:05) dalien: lets take asset server
(23:13:12) dalien: you have two methods basically:
(23:13:19) dalien: get(uuid): somedata
(23:13:23) dalien: store(uuid, somedata)
(23:13:36) lbsa71: IAssetServer.Get( uuid ) and IAssetServer.Store( uuid, somedata )
(23:13:46) dalien: in the local case they already contain the hooks to the database interfaces, right ?
(23:13:53) lbsa71: Yup.
(23:14:01) dalien: in the remote case they contain the hooks to the HTTP REST callers
(23:14:15) lbsa71: Yup
(23:14:21) dalien: plus in the remote case you need the HTTP rest handlers hooking up to the DB interfaces.
(23:14:46) dalien: so we change the call to be get(uuid, somemagickey)
(23:15:00) dalien: we need to change: local implementation, remote client implementation, remote server implementation
(23:15:06) lbsa71: Yes. Although, I would imagine the implementor GridAssetServer : IAssetServer takes care of both the REST bit and the DB bit?
(23:15:25) dalien: whereas in the case of "no direct" you would have to change only remote client and remote server
(23:15:29) lbsa71: But, there has to be something on 'the other end' of this as well.
(23:15:43) lbsa71: as you correctly points out.
(23:16:17) dalien: so in reality the win is maintaining 2 entities in the case of "no direct interface " while maintaining 3 entities in case of additional "sandbox" interface.
(23:16:40) lbsa71: I don't know if the remote client interface and the remote server interface can be said to be the same.
(23:17:12) dalien: nah, they are not the same indeed - but they have to match.
(23:17:28) lbsa71: The loss would be having to hack a crosswiring on the comm level instead of handling it in an explicit and structured way in building.
(23:17:28) dalien: i.e. if the OGS iterface in the opensim.exe changes now i would need also to change my ruby stuff
(23:18:17) dalien: I agree about the structured way. but it just means more maintenance.
(23:18:33) lbsa71: Ok, let me put it this way; I'm test infected.
(23:18:52) dalien: hehe ok. :)
(23:19:03) lbsa71: Though I'm not coding test-driven in this project, I've come to appreciate what TDD does to code structure;
(23:19:15) lbsa71: hence, I try to code my code as if it was driven by tests.
(23:19:44) lbsa71: And going up into the comm layer makes unit testing... well. Not unit testing.
(23:20:12) dalien: hm ok. :-) i think i was thinking similar thing, but at a network layer :)
(23:20:24) dalien: since with the sandbox/grid approach you need to double the number of unittests
(23:20:28) dalien: :)
(23:20:35) dalien: (ideally, that is)
(23:20:50) dalien: every change would need to be tested both against the local mode and grid mode.
(23:21:18) lbsa71: I think you and me are focused on two differnt spots in the protocol stack.
(23:21:30) dalien: yes :)
(23:21:40) lbsa71: I don't see a cross-wiring class as anything to maintain.
(23:21:53) dalien: but you agree about the unittests though ? :)
(23:22:23) lbsa71: On the contrary; in my experience, the ip routing approach will lead to more code that you have to understand; a cross-wire is trivial.
(23:22:49) lbsa71: No; per some kind of definition going up into the comm layer is not a unit test.
(23:22:55) lbsa71: That would be an integration test.
(23:23:03) dalien: dunno. maybe i am too much network-infected :-)
(23:23:19) lbsa71: Well, it's a question of faith.
(23:23:28) dalien: its more that we have a vivid example of that right now with the trunk
(23:23:35) dalien: assets work in sandbox mode
(23:23:46) dalien: and do not seem to work in grid mode at all
(23:23:52) dalien: (well, work = somewhat work :)
(23:24:07) lbsa71: I won't press the issue; I've already pleaded my case; I will go with whatever you all find more suitable.
(23:24:45) lbsa71: Well, at the moment we do not have the structure that I propose. (cheap shot, but true)
(23:25:13) GibsonWil left the room (quit: Quit: This computer has gone to sleep).
(23:25:17) dalien: hmm i understood that it was the class that was handling the communications depending on the local or remote case
(23:25:41) dalien: two classes - so exactly as i understand the "pluggable" idea. but i admit i did not study that in detail.
(23:25:45) CIA-1: opensim: lbsa71 Sugilite * r1209 /OpenSim/ (8 files in 5 dirs): * some follow up renaming of members et c.
(23:26:38) dalien: anyway, Adam is the "architecture lead" or ? :) should maybe just bring in the arguments, and then get someone make a decision
(23:26:57) lbsa71: Haha, I think we're all architectural leads.
(23:27:10) dalien: lol :)
(23:27:44) lbsa71: AdamZaius is mr Grid arch, MW region arch and me, I'm overall code coach.
(23:28:12) lbsa71: But this case clearly involves both grid and region, so.
(23:28:32) dalien: so we need to use the Universal Decision Maker: the coin ? :)
(23:28:34) lbsa71: I really think MW has 'the tounge on the scale' as we say in Sweden.
(23:29:21) lbsa71: No. I think we can reach an informed and unanimous descicion.
(23:29:36) dalien: yeah, i am fine with either approach. just think the two interfaces are a bit more maintenance + avoids seeing many "race condition" bugs
(23:29:49) dalien: which will inevitably show up in the case of grid setup
(23:30:05) lbsa71: I don't understand why you think of it as two interfaces. I think that is the problem.
(23:30:17) lbsa71: To me, it's one interface with two implementors.
(23:30:25) dalien: maybe my phrasing.. yes.
(23:30:37) dalien: so you have implementor of get(uuid)
(23:30:51) lbsa71: And, I think we should be discussing synch/asynch more than number of interfaces.
(23:30:59) dalien: which is local, and completes in 0.001 sec, not involving any of the networking stuff
(23:31:08) dalien: (and mostly always succeeds)
(23:31:08) lbsa71: We are having way too many synch requests.
(23:31:29) dalien: and then you have the other implementor of get(uuid), going over the wires
(23:31:41) dalien: which can succeed in 0.01 sec, or 10 sec, or not succeed at all
(23:32:32) dalien: with separating at the comms layer it is trivial to stick in the "delay pipes" or such for easy debugging even on the loopback
(23:33:44) lbsa71: Well, you're just pushing the 'hole' around. That is, the 'blind spot'.
(23:34:30) lbsa71: the point is that it's two completely different applications we want to be able to do with this framework.
(23:34:53) dalien: anyways... maybe we better hear first what the others think. I am not a fanatic of the "localhost" approach - if you think two versions is a better way, i won't argue too much - since with the "local"/"remote" approach it is always easy to fallback to "remote only" approach
(23:35:06) lbsa71: One aim is to have as few components as possible involved.
(23:35:55) lbsa71: is #176 still relevant?
(23:36:03) dalien: hmm i think it's just a matter of how you define "components"
(23:36:07) lbsa71: Sugilite build fails with errors in DB4oGridData.cs about not being able to find IGridData and IUserData ?
(23:36:15) dalien: #176 - the diff is not relevant, the problem is :(
(23:36:29) dalien: but it is a very minor one
(23:36:38) dalien: happens only with the first checkout, apparently.
(23:36:42) lbsa71: Hmmm. builds fine in my end. This a mono thing?
(23:36:49) lbsa71: Ahh. ok, will try.
(23:36:52) dalien: i do it on mono, yeah.
(23:37:01) dalien: the key is to do the clean checkout, then prebuild, then build
(23:37:08) dalien: it will fail
(23:37:12) dalien: then you do prebuild again
(23:37:29) lbsa71: Ok, I might know the problem actually...
(23:37:31) lbsa71: lemmesee
(23:37:33) dalien: and it will change the location in the .build file for one of the libs - apparently this causes build to succeed next time
(23:38:00) lbsa71: hhaha, ok, it's one more of those.
(23:38:03) lbsa71: Damn.
(23:38:09) lbsa71: Somebody's been copypasteing
(23:38:58) lbsa71: Okay, I found it.
(23:39:34) dalien: kewl. i was scratching my head yesterday for a while, but given that i am reverse-hacking the thing, proved a bit tedious, so i gave up :)
(23:40:44) dalien: once we sort what we do with #177, i'll re-checkout the fresh build and can verify the fix :)
(23:43:08) MW__ [M@87.112.87.16.plusnet.ptn-ag2.dyn.plus.net] entered the room.
(23:43:18) dalien: oh btw seems we have a candidate for animations but he/she is on the teen greed - posted to check out the details why does this matter (prolly the bounty, i suppose :)
(23:43:34) dalien: hm teen grid :)
(23:45:16) MW__: hrmm, we really need to have logs of this channel somewhere, seems my computer lost connection about a hour ago, so I've missed anything said in that time
(23:47:21) dalien: MW: i can copypaste on the pastebin ? (for long term: yes, good idea... let me google on it)