[06:26] *** salmon_ has joined #kamaelia

[07:52] *** vmlemon_ has joined #kamaelia

[08:23] *** Uraeus has joined #kamaelia

[08:29] *** salmon_ has joined #kamaelia

[09:33] *** Lawouach has joined #kamaelia

[10:53] *** Uraeus has joined #kamaelia

[11:42] *** Uraeus has joined #kamaelia

[12:54] *** vmlemon_ has joined #kamaelia

[13:42] *** Uraeus has joined #kamaelia

[14:05] *** vmlemon__ has joined #kamaelia

[14:28] *** vmlemon__ is now known as vmlemon_

[15:02] < MS-> Ha! Getting to closer to getting this bugger working. It's trying to send messages from the wrong user.

[15:02] < MS-> Now I just need to figure out *why* that's the case :-/

[15:04] < MS-> Oh my. It's *massively* hardcoded it seems. That's why.

[15:06] < MS-> OK, message still not getting anywhere, but at least identified how to test it better...

[16:06] < Lawouach> hmm

[16:06] < Lawouach> I feel you're talking about xmpp :)

[16:09] *** vmlemon__ has joined #kamaelia

[16:14] *** vmlemon__ is now known as vmlemon_

[17:39] *** vmlemon__ has joined #kamaelia

[17:45] *** vmlemon__ is now known as vmlemon_

[18:46] *** MS- has joined #kamaelia

[18:51] *** vmlemon__ has joined #kamaelia

[18:51] < MS-> I've decided to give up on Jason's XMPP code

[18:51] *** vmlemon__ is now known as vmlemon_

[18:53] < MS-> It's all just too painfully tied up.

[19:00] < MS-> Oh, I think I *may* understand what's going wrong.

[19:01] < MS-> maybe

[19:02] < MS-> I think my problem really here with jason's code is the lack of encapsulation

[19:02] < MS-> Means that things don't hang together cleanly

[19:04] < MS-> I don't also see how Jason's code could ever have actually worked

[19:04] < MS-> Unless he was breaking it near the end of GSOC

[19:04] < MS-> Since the XMPP messages aren't being sent from the "right" user

[19:05] < MS-> and going astray, I think, as a result

[19:07] < MS-> If I understand this correctly, it looks like you login to a server.

[19:07] < MS-> The server then allocates you a jid

[19:07] < MS-> your messages then have to come *from* that jid in order for things to work

[19:07] < MS-> Jason's "Interface" component skips that step

[19:15] < MS-> OK, now found *where* this thing is, in theory, defined.

[19:15] < MS-> in theory

[19:39] < MS-> **** And the crowd goes wild ****

[19:39] < MS-> I *knew* the CAT would be useful, one day

[19:42] < MS-> OK, whilst slightly annoying I understand the logic of why that happens, and get it working the way it's supposed to.

[19:45] < MS-> In case anyone's reading this and going "WTF"? The thing that's working here is that I'm completely sidestepping the way headstock is supposed to be used

[19:45] < MS-> And sidestepping how Jason's code from last year doesn't quite understand headstock

[19:45] < MS-> By deliberately choosing to create a system global value

[19:45] < MS-> using the cat

[19:45] < MS-> ie using this :

[19:46] < MS-> import Axon

[19:46] < MS-> from Axon.CoordinatingAssistantTracker import coordinatingassistanttracker as cat

[19:46] < MS-> if self.dataReady("jid"):

[19:46] < MS-> self.from_jid = self.recv('jid')

[19:46] < MS-> print "NEW MYJID", self.from_jid

[19:46] < MS-> try:

[19:46] < MS-> cat.getcat().trackValue("MYJID", self.from_jid)

[19:46] < MS-> except Axon.AxonExceptions.NamespaceClash:

[19:46] < MS-> cat.getcat().updateValue("MYJID", self.from_jid)

[19:46] < MS-> print "MYJID", cat.getcat().retrieveValue("MYJID")

[19:46] < MS-> In order to set the global sender id - since I can guarantee only one sender

[19:47] < MS-> And inside the sender component, which is guaranteed to be started later

[19:47] < MS-> I can grab this global value thus:

[19:47] < MS-> myjid = cat.getcat().retrieveValue("MYJID")

[19:47] < MS-> self.ThisJID = myjid

[19:47] < MS-> And thus the system hangs together.

[19:48] < MS-> At least one way :-)

[19:50] < MS-> Key thing from my perspective here isn't whether it's clean - it's the fact it IS working, which means it can be made to work, and then cleaner :-)

[19:52] < MS-> OK, not going to give up now, but I will call that success for tonight :-)

[19:53] < MS-> tis a remarkably sweet thing to see one of jason's "crosstalk" messages arrive on the other end of the XMPP connection :-)

[19:53] < vmlemon_> Trying to untangle spaghetti?

[19:56] < MS-> Yes.

[19:56] < MS-> And actually getting somewhere too.

[19:56] < MS-> To be fair also, the vast majority of Jason's code *does* hang together

[19:56] < MS-> with an internal logic.

[19:57] < MS-> It's not a logic I would've used, but it is relatively self consistent

[19:58] < MS-> In case it seems wierd to be trying to figure out this stuff.

[19:59] < MS-> The nice thing about doing this is that it'd be a potential route for someone to be able to

[19:59] < MS-> run a google app-engine application locally

[19:59] < MS-> rather than "in the cloud"

[19:59] < MS-> but still have it accessible by the rest of the world

[19:59] < MS-> At least that's one possible direction to extend it to

[20:00] < MS-> Since it acts as a wsgi host, in the same sort of way app-engine does

[20:00] < vmlemon_> Aah, cool

[20:02] < MS-> I think there'd be a need for a lot of simplification in the code/etc based on what I've read etc

[20:02] < MS-> But it's definitely a good starting point, primarily because I can see it will work :)