[00:08:05] _jpl_: sent the zip [00:09:06] <_jpl_> Got it, taking a look. [00:50:19] <_jpl_> I think I'm getting somewhere... [01:03:32] _jpl_: excellent-- I just tried consolidating the EchoSchema.xml with what I had in component.xml, but that didn't seem to do anything... [01:19:49] you guys going to post your work somewhere i.e. the 'echo' example when the bugs are worked out? [01:20:00] <_jpl_> Definitely [01:20:40] <_jpl_> I have a pretty sketchy idea of what's going on (and going wrong), but will need a little more time to nail it down completely. [01:22:13] :) [01:22:21] i just figured out how to make a peak script runnable today ! [01:27:25] Maniac: RE: runnable script-- cool. This week is pretty much the first week I've done any PEAK stuff, so I'll have to learn the executable script as well-- after this damn twisted demo gets working that is... [01:28:53] well, all of pje's explanation is in today's chat log :) [01:29:32] _jpl_: So what's your sketchy idea of what's wrong w/ the twisted-echo demo? I'm re-reading ZConfig docs (I"m assuming that's where the prob is) now, trying to get my head around it. [01:30:27] <_jpl_> Just a minute... [01:32:02] <_jpl_> Aha! I think... [01:33:38] * salivates [01:48:41] <_jpl_> I think I've nudged it slightly farther ahead, but not there yet... [01:58:31] _jpl_: every little bit helps. I think we'll have jack-e to dig in on this as well. He said he may have some cycles for this on his next work iteration. (I think he's in Germany) [01:59:34] _jpl_: maybe we should post what we have so far to the list. It might be something that pje would be able to spot and fix really quickly. [01:59:38] <_jpl_> Yes, he's in Germany [01:59:55] <_jpl_> pje is most likely gone for the day... [02:03:50] <_jpl_> Ok, one thing is that EchoSchema.xml should most likely be a direct copy of EventDriven.xml [02:06:48] <_jpl_> Another thing is that you needed "from twisted.internet.protocol import Factory" at the top of eventrunner.py [02:07:08] <_jpl_> er, echorunner.py [02:07:19] ok-- I can try doing that. [02:08:02] <_jpl_> And since the ZConfig file is not XML, I'd recommend not naming it with a .xml extension. [02:08:38] right-- should be zcml I guess [02:10:21] <_jpl_> Oh, when you copy EventDriven.xml you want to add [02:13:55] so do you think I should also copy the peak.running.component.xml file to be in the same dir as EchoSchema.xml? That's one of the things that I don't really understand. Apparently when you do the import package="..." directive, ZConfig automagically looks for a component.xml file. Ugh-- frameworks that do a lot of black-magic stuff behind the scenes can be a PITA when first learning them... [02:14:03] <_jpl_> It looks like EchoRunner.__onstart is not being called. [02:15:02] <_jpl_> No, you don't need peak.running's component.xml, since you'll keep EventDriven.xml's line [02:15:03] RE: onstart-- yeah, I put some print stmts in there, and nothing got printed. [02:15:45] <_jpl_> (so ZConfig will find it automatically) [02:16:27] <_jpl_> I put a "1/0" in __onStart and... nothing. [02:16:59] ah, ok. So I should just add what I have now in the component.xml file (in the dir w/ EchoSchema, not peak.running.component.xml) to the bottom of EchoSchema.xml? [02:17:24] <_jpl_> No, you need to leave your component.xml as is. [02:18:34] Oh. Ok. Is the component.xml thing documented somewhere in the ZConfig doco? I don't remember seeing that. [02:18:52] <_jpl_> By saying implements="running.Task" in your component.xml you make it possible for ZConfig to implement your EchoRunner sectiontype automatically. [02:18:56] <_jpl_> I think. :) [02:19:45] <_jpl_> Yes, section 3.2, "Schema Components" [02:19:58] ok-- well this is *sort* of making sense. [02:20:13] <_jpl_> Alright, so EchoRunner is definitely not being instantiated... [02:20:16] I'll look at that section, thanks. [02:22:59] Do you know how we could crank up the debug output of the PEAK framwork when its loading this file? [02:23:39] <_jpl_> I'm doing that now in fromZConfig using good old print statements. [02:30:39] <_jpl_> Ok, so EchoRunner definitely *is* being instantiated. :) [02:32:10] Hmmm.. so is it just not being bound in the component tree? [02:32:28] <_jpl_> It's not running __onStart for some reason. [02:33:17] I'm assuming binding.whenAssembled is called when it is bound in the top-level app context. [02:33:53] <_jpl_> EchoRunner.port is getting set properly, though... [02:34:08] <_jpl_> Something like that, yes. :) [02:34:13] I just tried changing the log level to logs.ALL in peak.ini, but I got no output. [02:34:37] RE: port being set-- well that's good. [02:36:40] <_jpl_> There are no log statements within Component.fromZConfig... I'm inserting print statements there to see what it's doing (it seems to be the crucial point of the process) [02:37:46] <_jpl_> Ah -- attempting to look at __onStart directly generates an exception: "Recursive attempt to compute attribute" [02:38:49] what did you mean by "look at __onStart directly"? you mean in a pdb session? [02:39:43] <_jpl_> No, in a print statement inserted into peak.binding.Component.fromZConfig [02:41:25] <_jpl_> Hmm, actually, there's something weird about __* names... [02:41:51] oh, ok. [02:42:42] RE: weird __* names-- Well, they should be mangled right? Isn't that python's (weak) way of doing private vars? [02:43:25] <_jpl_> Yes, but Python doesn't actually *do* anything with them. Though it seems peak.binding.Component does. [02:43:31] wouldn't the real name of __onStart be _EchoRunner__onStart or something like that? [02:44:21] Oh, you mean pje does some additional mojo with them... Hmmm I faintly remember something about that. maybe on the maillist. I'll search. [02:46:21] <_jpl_> No wait, you're right, Python does mangle them [02:46:42] <_jpl_> I had forgotten that little tidbit of Pythonic black magic [02:50:02] ok, I didn't find anything on the maillist detailing any __* black magic, but that doesn't mean its not there! [02:50:30] <_jpl_> I didn't see any in binding.Component [03:09:54] _jpl_: can you tell me what file/line you've traced to so far? I'd like to start putting in some pdb stmts and step thru some of this code... [03:12:16] <_jpl_> I'm now focusing on peak.running.commands.EventDriven [03:12:48] <_jpl_> Specifically, I'm examining the contents of self.components, which is where the EchoRunner instance lives. [03:13:35] Hmm. ok. [03:17:32] I definitely don't like pje's coding style of leaving large amounts of space in between sections of code in his files. A number of times when scanning a file, I'll think I'm at the end and close it to move on to another, then realize later that there was a bunch more code in the file. [03:18:14] <_jpl_> So EchoRunner gets instantiated into an item in the components attribute of the EventDriven object. Fine. In theory __onStart should be setup automatically, but it isn't for some reason. [03:18:55] <_jpl_> Yeah, the same thing happens to me. I've been meaning to ask him where all that space comes from. Looks like something a code generator or some other automated tool would do. [03:24:16] reading peak.binding.whenAssembled doesn't really give any insight... [03:42:09] damn-- I *know* this is going to end up being a one-liner config error. I just tried doing pje's quick-n-dirty solution that he posted to the maillist, and its just hanging as well. He said that he got that part working earlier. Ugh. [03:52:30] Hmmm.. ok, I got the quick-n-dirty app to work (woopee!). I'm now wondering if the hanging is due to some funkiness w/ the invoke cmd. Do you want me to send you the files I have? [03:53:47] <_jpl_> Which part did you get to work? [03:54:59] bypassing the ZConfig and just instantiating EchoRunner directly (In other words, PEAK+twisted works). [03:56:04] <_jpl_> Are you still using EventDriven (or AbstractCommand?)? [03:58:13] Yes-- I'm using a class called EchoCommand that extends EventDriven. EchoCommand just binds EchoRunner to a var named commands. It runs. I can telnet to it and it echos input back. So that's at least something. [06:00:30] Think its time to hit the sack.... [06:06:47] <_jpl_> Same here. Talk to you later. [06:08:55] k see you tomorrow. I'm going to send what I have so far to jack-e (that's Ulrich from the maillist right?). Maybe he can take the ball further... [06:10:11] <_jpl_> Yes, jack-e is Ulrich. [06:10:32] ok, cool. Thanks. [06:10:34] <_jpl_> You might also send it to the mailing list. Like you said, pje can probably solve it in a minute or two. [06:11:53] good idea. [10:06:22] _jpl_: You around? [10:59:34] --> jack-e has joined #peak [10:59:44] re [12:02:01] * jack-e is gone (2:02PM): .. autoaway .. [12:06:49] jolby: did you post to jdeb about the python-jabber server ?? [12:07:09] s/jdeb/jdev@jabber.org [13:08:01] * jack-e is gone (3:08PM): .. autoaway .. [13:24:34] --> |Darks| has joined #peak [13:46:18] heya darks :) [13:48:10] --> Maniac has joined #peak [14:06:19] morning [14:13:36] helo maniac .. i saw in the logs that you've had long talks yesterday :)) [14:14:13] i'm out of office for a while and back later [14:14:27] --- jack-e is now known as jack-e|brb [14:24:06] yup [15:01:57] i actually understand most of the example app now that i understand runable scripts :P [15:07:42] --- jack-e|brb is now known as jack-e [15:08:05] :) [15:14:05] wb jack-e [15:14:19] busy chat day yesturday again with pje himself showing up [15:14:42] i read throug the logs this morning .. i saw it ;-) [15:15:26] you know what the problem with programming in your spare time is? [15:15:43] i have more project ideas and things i'd like to do than there are years in my life [15:15:58] and almost none of them get done :P [15:16:35] i know this situation .. i have so many unfinished things here as well [15:25:00] http://mailman.jabber.org/pipermail/jdev/2003-July/015990.html [15:26:07] about the twisted-jabber-server in python ?? [15:28:10] yes [15:28:40] i would also post it to the Twisted-Python list [15:40:49] i've downloaded it and read through the code .. [15:40:59] there is lot's of stuff to peakify :) [16:30:52] mornin' folks [16:33:04] hey jolby :) [16:33:05] well, its morning here at least :-) [16:33:34] where are you located ?? [16:34:13] west coast of U.S. (Bellingham, Washington). How about you? [16:34:31] Europe/Germany/Munich [16:35:48] Oh, so you're probably closer to the end of your day than the beginning. Unless you're a nocturnal coder. [16:36:29] :) [16:37:00] did you post the link to twijab on jdev ?? [16:37:46] No-- I just saw that last night, its another fellow. We've got a harmonic convergence of jabber servers written in twisted! [16:38:10] ahh .. ok :)) [16:40:00] did you look at the code ?? [16:40:04] I need to contact that guy to see if they'd like to join forces. At the least they may want to use my unit tests [16:41:26] I did do a glance over the code last night (but I was tired after looking thru PEAK code all day). It looks pretty nice and lightweight. [16:43:12] i'm still wondering how to create a setup for such a server that really makes sense (e.g. make protocol a component that lives in the context and therfore can use peak-facilities) [16:44:03] you get one instance of the protocol-handler per connection afaik .. so you'll need to manage all this somehow [16:44:40] Did you see the twisted-echo example that I posted to the list? [16:45:04] i unpacked but i think i did not read it .. mompl [16:46:51] but you just say protocol = Echo .. that's what i meant .. within the Echo-instance you have no access to you "parent", config, naming, etc .. [16:47:08] but that especially is the place where you need it [16:48:58] --> pje has joined #peak [16:49:03] so you'ld probably a custom factory that creates a Protocol-Component and set it up correctly for peak and twisted [16:49:08] hey phillip :) [16:49:17] Hey. [16:49:36] Or, you can create a local class, with a closure to get your context. [16:49:49] we're just talking about how to get further on with the twisted server example [16:50:20] the thing is that the Echo (protocol) instance right now is not "plugged" into peak's context . [16:50:34] That is, in the '__onStart' method, create a local subclass of self.protocol, with a def getContext(s): return self [16:51:06] Now, every Echo instance can use self.getContext() to get the EchoRunner. [16:51:38] There is probably a less ugly way, if you know more about Twisted, but I don't. :) [16:51:49] i haven't looked closely at the implementation of factory/protocol [16:52:07] Btw, to answer a couple of questions from the log... [16:52:36] The __onStart is nothing special... you could have called it onStart just as well. I just use __ for whenAssembled methods because you will never call them directly. [16:52:45] Thus, you might as well make them private. [16:53:06] Second, if you wonder why those blank lines are in my source code, set your editor to exactly 41 lines per screen. :) [16:54:06] * pje hates to scroll through code [16:54:43] wow-- I step upstairs for coffee and look at all the action I miss! [16:56:30] Jolby: did you get your ZConfig working? [16:57:03] jack-e: I was thinking that we'd need to have a custom factory as well. That's what I'm doing for the twisted-jabber code that I have so far. [16:57:26] pje: I was just getting ready to start in on that again (the coffee's kicking in...) [16:58:04] Ohhh-- so *that's* the reason for the spacing. So you just to pgup/pgdown? [16:59:04] Yep. [16:59:09] yes .. overwrite the buildProtocol method and let Factory be a binding.Component as well, within buildProtocl then do a p = self.protocol(self.getParentComponent()) [16:59:18] It gives me a sense that the code is "where I left it". :) [16:59:45] I can also easily spot constructs I'm looking for, and have a sense of the overall size of a module. [17:00:01] It's an old habit, burned into my brain well over a decade ago. [17:00:11] jolby: then the protocol-instance should be plugged into naming/etc [17:01:19] pje: what do you think about playing peak.web nicely with twisted.web ?? it'ld be a fairly lightweight alternative to fast-cgi (and pure-python) [17:01:31] jack-e: Yep-- that's what I was thinking of doing. Maybe once we get the simple echo srver working, we could do another simple "message of the day" server that gets its messages from some (in memory) db provided in the context. That would be a good example for getting a handle to other components (or would that be called a "utillity"?) [17:02:11] Jack: I expect that to happen at some point. First, I want to create a "trivial CGI" example program. [17:02:22] ok [17:02:39] Then, hooking up twisted.web (or really, twisted.protocols.http) to run CGIs similar to the FastCGI CGI runner in PEAK. [17:02:59] Once we have those steps, then it should be possible to run any peak.web via a Twisted server. [17:03:04] my thoughts [17:03:17] pje: Are you going to create your own template mechanism for peak.web? Or do you plan on using (porting?) some other framework like ZPT or cheetah? [17:03:34] and there is already a twistedzope.py in sandbox that helps with the setup of all that a bit i think [17:06:25] Our own template mechanism. I like Twisted's "woven", but it's not directly usable for a variety of reasons. [17:06:51] So, we'll be using something that looks an awful lot like Twisted's MVC attribute syntax. [17:08:17] woven seems to be very (x)html specific .. i'ld need pure-xml-output more than html [17:08:44] (at least at some points woven makes assumptions that you're using it as html-template, which is bad imho [17:08:45] ) [17:09:03] I used to use Enhydra's barracuda+XMLC template system when I was in java-land. Pretty cool stuff. Especially barracuda. [17:10:19] I've looked at an *awful* lot of templating systems. Twisted's approach is the least invasive I've seen, that doesn't also push formatting knowledge into code. [17:10:56] Actually, the only thing *less* invasive I've seen is PyMeld, but it pushes too much formatting knowledge into the code that uses it. [17:11:29] woven does not use namespaces for it's *special-tags*, right ? [17:11:37] err not tags but attrs [17:11:53] They don't, but PEAK will, or at least will have the option. [17:12:28] fine .. it's ok for html-output only .. but when you want to ouput arbitary xml this would not work anymore [17:12:59] * pje nods. I don't intend it to be HTML-specific. [17:13:36] do you have a timeframe for the template-stuff ? [17:14:08] pje: So that fix you put into cvs, will that fix the problem of EchoRunner.__onStart not being called? Once I get the ZConfig schema wired correctly that is... :-) [17:14:31] we're planning an internal sprint-weekend where we want to connect peak through xml with a xslt-frontend in september/october .. [17:14:57] Jolby: yes. That is exactly what it fixes. I hacked on your code this morning and that's how I found the bug. [17:15:16] pje: Ok, cool. I'm updating now. [17:15:45] Jack: actually, I was planning to start working on templates today. [17:15:59] ok .. so then i stop talking to let you start ;-) [17:16:23] But I'm probably not going to. I want to get "trivial CGI" built first, to check that all my moving parts for CGI still work. [17:16:49] At the rate things are going, I probably won't hack templates in earnest until the weekend. [17:17:06] you'll probably need a getObject Method in the ComponentAsLocation class if i understand it correctly [17:18:09] Oops, looks like that was lost in editing. [17:18:38] Good catch. :) [17:18:51] * jack-e is watching you ;-) [17:19:36] * Maniac returns from the meeting from hell [17:21:19] pje: an interaction would be called Task in zope3 ?? [17:21:38] Jack: dunno. Technically, it's a Zope 3 "publication". [17:22:00] that the publisher uses [17:22:07] Except that Zope 3 tends to reuse a single publication instance for all requests, and PEAK will have one interaction instance per request. [17:22:29] ok [17:22:47] You can think of interaction as an "application-specific super-request" [17:23:04] You can put any bindings in it that your application needs that are specific to a given request. [17:24:17] so .. would you then compose a bulletin web thingie as e.g. BulletinInteraction(BulletinApp, BaseInteraction) ?? [17:24:27] pje: Should my EchoRunner section type extend anything? You said it should not extend AdaptiveTask [17:24:47] Jolby: no, all it needs is the port, so there's nothing to extend. [17:24:59] k. thanks. [17:25:02] Jack: No, you wouldn't do that, because the interaction is not the app. [17:25:08] ok [17:25:17] An interaction represents a single interaction *with* the app. [17:25:36] You want the app instance to live across interactions, so it keeps DB connections open, etc. [17:25:52] Anything that is global to all requests (interactions) should stay in the app. [17:26:02] Things that have to be computed for each interaction, go in the interaction. [17:26:19] ok .. [17:26:21] BaseInteraction has an 'app' binding to refer to the application. [17:26:42] so .. session-management (at least parts of it) would extend the BaseInteraction ? [17:26:43] then [17:27:03] You'll notice also that CGIPublisher is an adapter over Component (such as your app) to IRerunnableCGI. [17:27:32] So, basically, if you adapt your "app" to IRerunnableCGI, that will give you a publisher. [17:27:45] Jack: yes. [17:27:54] sounds good .. [17:28:28] If you need a subclass of BaseInteraction, currently you also have to subclass CGIPublisher, set its 'interactionClass' to your new interaction, and then proceed from there. [17:28:47] But I think maybe I should change that, so that 'interactionClass' is bound to a configuration property looked up on the app. [17:29:18] yup [17:29:46] I guess I'd need to do the same for locationProtocol and behaviorProtocol. [17:31:25] And I suppose if I also do it for the 'mkXXX' request types, then there'd never be a reason to subclass CGIPublisher, short of protocol changes. [17:31:44] makes sense to me [17:32:22] Nice. :) [17:38:42] Okay, I've made the changes now, so it all goes through the config system. No subclassing needed. [17:39:06] I didn't change out the mkXXX stuff... seems like a YAGNI for now. [17:39:33] yeah .. if needed you can subclass as well [17:40:33] Woohoo! got it to work using ZConfig. I had to *not* use invoke, and just invoke peak like so: exec peak zconfig.schema:src/twistedpeak/EchoSchema.xml ./tp.zcml [17:41:09] Hm. Are you sure invoke is the problem? [17:41:11] the tp.zcml being the [17:41:12] Port 8080 [17:41:13] part [17:41:28] Well, at least for me it was. :-) [17:41:50] <_jpl_> Hello all. [17:41:53] when I use invoke, it just hangs. [17:41:56] What #! line are you using now? [17:41:57] hello john [17:42:06] Or are you not using a #! line? [17:42:26] pje: #!/bin/sh [17:42:48] _jpl_: good timing, we just got the ZConfig based echoserver to work. [17:43:13] * pje raises an eyebrow [17:43:17] Interesting. [17:43:32] <_jpl_> Excellent. I was just looking through the logs and realized I forgot to mention the extends=AdaptiveTask thing. [17:43:49] You should be able to put #!invoke peak zconfig.schema:src/twistedpeak/EchoSchema.xml at the top of your tp.zcml file, and just run tp.zcml. [17:44:11] pje: on my system using !#./invoke is broken. It was broken for the quick-n-dirty example as well. [17:44:24] I'm using RH 7.2 [17:44:50] Okay, you can always try just using !#peak whatever if your kernel supports scripts as interpreters. [17:45:05] But that'll only work if there's only one argument after 'peak'. [17:45:25] How did you build invoke? [17:45:54] I just built it like it says in the INSTALL [17:46:38] And there were no error messages? [17:46:59] Try just typing 'invoke echo test' at the shell and see if it runs. [17:47:22] pje: no-no msgs, it just hangs. I shouldn't say categorically that it is broken. I did get it to run your bulletings ex. [17:47:31] Hrm. [17:47:34] Ok, I'll try that. [17:47:37] Interesting. [17:48:08] as far as i can tell, invoce works with debian and gcc3 [17:48:20] s/invoce/invoke [17:48:28] pje: typing invoke echo test works [17:48:46] Okay, try 'peak true' -- what happens? [17:48:54] (No invoke, just 'peak true') [17:49:05] Its just when I try to run the echoserver scripts-- hmmm wonder if its choking on the env PYTHONPATH stuff??? [17:49:34] Try just typing 'env PYTHONPATH=something echo test', then. [17:49:41] typing "peak true" just runs w/ no output [17:49:50] And then 'invoke env PYTHONPATH=something echo test'. [17:50:05] Okay, that was just to see if 'peak' was on your path. [17:50:46] should that last one be: env PYTHONPATH=something echo test or: env PYTHONPATH=something invoke echo test [17:51:03] Just what I typed. [17:51:23] both worked. Hmmm. [17:52:01] Hmm indeed. [17:52:46] Why don't you try setting up the #! line without env or PYTHONPATH, and then just run PYTHONPATH=whatever tp.zcml? [17:52:56] Then at least we can see if invoke is working correctly. [17:53:22] So tp.zcml should start w/ #!invoke peak zconfig.schema:path/to/whatever.xml [17:53:59] <_jpl_> Phillip, (hopefully) a quick question. Using "peak zconfig.schema:foo.xml" to start an application, how would I duplicate the "[Load Settings From]" behavior? In my ZConfig schema I have my "app" object (with .fromZConfig, of course) as the datatype for the schema, but it seems that it's not getting a configuration root at run time. [17:54:08] And btw, please drop the .zcml, we don't want people to confuse ZConfig and ZCML... maybe .zcfg? [17:54:45] JPL: it should get a root. [17:55:38] Ahh-- this is interesting. I made a quick test script that has the #!./invoke env PYTHONPATH=blahblahblah:blahblablah echo test and it hangs. So invoke works on cmd line, but seems to choke on the file. [17:56:13] Oooh... I think I know the problem. [17:56:24] Some OSes have a maximum length for a #! line... [17:56:30] That's probably what's breaking. [17:56:40] Ahhh-- makes sense. [17:56:47] I think Linux has 127 chars max. [17:57:10] Some OSes only let you have 32! [17:57:23] Yikes! [17:57:26] if i do a ./invoke mine breaks i have to use absolute path i.e /usr/local/bin/invoke [17:57:34] <_jpl_> When you say "it should get a root", does that mean PEAK should be providing one for it, or I should be providing one for it somehow? [17:57:40] in terms of #!/usr/local/bin/invoke [17:57:43] Yeah, some OSes require an absolute path for #! too. [17:57:51] #! portability *sucks* [17:58:05] JPL: PEAK should provide one, if you're using 'peak whatever' to run it. [17:58:59] How did you determine that it's not getting one? [18:01:46] <_jpl_> Ok, I think the problem is that I'm instantiating a few other things in the __init__ method of one of my components. Is there another method that gets called on components after everything gets setup? [18:04:49] pje: you're right about 127 char limit on linux. Above 127 it will start start dropping chars [18:05:23] That's fine. shell scripts work fine for me. I'm just glad to know what was causing the hanging. [18:09:06] JPL: create a method and wrap it with binding.whenAssembled() [18:09:40] The method will take '(self, d, a)' params (see the echo example's __onStart method) [18:09:59] <_jpl_> Thanks, I'm already trying that. :) [18:16:23] <_jpl_> Is there a way to have arbitrary property names when using ZConfig? That is, property names that don't necessarily get assigned, but can be looked up in various components. [18:16:59] Nope. Property names are a PEAK thing; ZConfig doesn't do that. [18:17:16] That doesn't mean you couldn't create a section type for properties, using PropertyName as a keytype. [18:17:43] Problem is, you'd have no way to specify the datatype for each property. [18:17:47] <_jpl_> Right, so any thoughts on how I might get the same sort of behavior? Is it possible to use offerAs in conjunction with ZConfig-assigned properties? [18:18:08] ok-- I've got the twistedpeak echo demo cleaned up a bit. I placed the EchoSchema.xml under the /schema dir, and the tp.zcfg under the /config dir. All runs pretty nicely. PJE: should I post this to the list?, or do you frown on posting attatchments to the maillist? [18:18:16] JPL: Let's take a step back. Why do you want this? [18:18:42] I prefer no attachments; our mailman doesn't know how to archive them properly. [18:19:05] <_jpl_> I have some settings that are needed across the application, so I've been looking them up as properties. [18:19:09] Jolby: may I also suggest you combine all the .py files into one? It's so little code there's no point in separate files. [18:19:47] Gotcha. This is where a wiki+cookbook type of thing would be useful. [18:19:51] JPL: if the set of properties is known and fixed, then use offerAs on attributes, and then set up the schema to set those attributes. [18:20:11] So they will be configured by ZConfig, and then published by peak.binding. [18:20:23] <_jpl_> Ok, that's what I was thinking. [18:20:39] RE: separate files. sure-- that's no prob. [18:20:40] I thought you were asking about *dynamic* properties. [18:21:35] Jolby: once I get ZConfig to be able to extend schemas properly, I'll probably just make Echo a standard example in the distro. [18:22:26] <_jpl_> Ah, well, I was going to ask about dynamic properties at some point... [18:23:51] Yeah, well, once you have an *actual* use case for them, I'll take the time to explain how to do it. [18:24:19] It's too hairy to want to do it casually, and it defeats the purpose of using ZConfig - i.e. a simple, relatively fixed schema. [18:25:21] <_jpl_> Here's one: user changes some things in the config file and sends my agent a SIGHUP, expecting it to re-read its configuration. [18:29:05] Reinstantiate the app. [18:29:26] <_jpl_> I thought that might be the answer. :) [18:29:37] To be precise, you need a custom bootstrap class to use in place of the one used by the 'peak' script. [18:30:01] This is still faster than exit and restart, since Python is loaded and all needed modules are already imported. [18:30:26] <_jpl_> Ok, I'll look into that at some point. [18:30:32] And depending on whether you're promising to reload PEAK_CONFIG/peak.ini stuff on SIGHUP, you might be able to keep the same config root. [18:31:33] Note that your SIGHUP handler also needs to be able to break out of your current execution. [18:31:50] Including perhaps stopping the reactor, if you're running an event-driven app. [18:32:40] I suppose it might be useful to add something like this to the "interpreter" command classes, so they can be told to restart the config file they're "interpreting". [18:36:04] * pje has got to go get some food [18:36:13] BBIAB [18:36:31] @all: should we register a project at sf.net for peak-projects, examples etc ?? [18:36:51] there is collective for zope/plone and it seems to work fairly good (i contribute there too) [18:38:31] <_jpl_> Sounds like a great idea. [18:38:53] hmm if i remember correctly .. pje setup a wiki on telecommunity.com already .. that might be another option [18:39:30] <_jpl_> Oh that's right, there is a wiki. [18:39:46] <_jpl_> It's just not published on the main page for some reason. [18:39:54] the url is somewhere in the mail-archives .. [18:40:37] <_jpl_> From back in December or November, I think. [18:41:24] a wiki with code-snippets and recipes would be sufficient for now i think .. the sf-project can be registered when we found a good name for it ;-) [18:42:17] http://peak.telecommunity.com/DevGuide [18:42:31] was the one in the mail .. no clue if it's still there [18:43:04] yep [18:43:42] jack-e: just caught up-- great idea. I think it would help people get up to speed *much* faster. [18:44:40] JPL: "some reason" = there's not much content there. :) [18:45:15] <_jpl_> Mind if we start putting some there? [18:45:17] If anyone here wants it, I have cleaned up the twistedpeak-echo app, and its working properly now. I can send it via email if anyone wants it. [18:46:47] <_jpl_> Arg, ZConfig isn't setting my properties to the appropriate data type. e.g. a "port-number" typed property (or even an "integer" for that matter) becomes a string in the actual component. [18:47:04] jolby: i'm interested (ueck@net-labs.de) [18:51:00] _jpl_: The echo example correctly sets the port number using a ZConfig parameter. I can send it to you as well as jack-e. [18:51:26] gah pje uses mIRC [18:51:45] if you put examples on a wiki other people can correct/comment too i spose [18:51:48] JPL: Go for it. [18:51:50] <_jpl_> And the port number becomes an actual integer? [18:52:07] moinmoin allows attachments too iirc [18:52:20] ya-- you define that in the component.xml file -- did you do that? [18:52:34] can also post IRC channel etc. on wiki [18:52:48] Maniac: when I needed to get on IRC, I just downloaded the first IRC client I knew of. [18:52:53] Maniac: RE: wiki-- ya-- we were just talking about that. I think that would help a lot of people out. [18:53:36] <_jpl_> Yes, the property is defined in a component.xml file. [18:54:31] _jpl_: Hmmm... [18:56:06] <_jpl_> Phillip, have you ever seen this behavior with ZConfig properties, .fromZConfig, and datatypes? [18:56:36] Nope. [18:56:46] --- jack-e has changed the topic to: PEAK development (http://peak.telecommunity.com) - DevWiki hidden at: http://peak.telecommunity.com/DevGuide [18:56:57] <_jpl_> Joel, the wiki does allow file uploads. [18:57:42] <_jpl_> Phillip, might the wiki need to be repurposed from a DevGuide to more of a developer community wiki? [18:57:50] Ok, great-- I'll just post to the wiki then. Is that ok w/ everybody? Ulrich-- do you still want it via email? [18:58:14] <_jpl_> The DevGuide would then be a topic under the main wiki site. [18:58:27] JPL: I'm not sure it's that critical. [18:58:28] jolby: nope (now that i can remember the url) [19:01:35] --- jack-e is now known as jack-e|dinner [19:01:46] bbl [19:06:25] <_jpl_> This is frustrating. No matter what datatype I specify in component.xml, the property is being set to a string. [19:06:52] Weird. [19:07:03] I've never had that happen. [19:08:24] <_jpl_> In fact, if I specify "integer" in component.xml but provide a string it goes through ZConfig just fine. [19:09:41] I'm confused now. [19:09:50] You're saying it works if you specify integer as the datatype? [19:09:55] Or...? [19:10:14] <_jpl_> No, what I meant is that ZConfig should complain about the string (where an integer should be provided), but it isn't. [19:10:26] How are you "providing" a string? [19:10:35] <_jpl_> In the actual config file. [19:10:36] Note that ZConfig files don't quote strings... [19:10:54] <_jpl_> I give it "x" (no quotes) instead of a port number. [19:11:00] Ah. [19:11:26] You've got me there... I've never seen anything like that. [19:11:51] Are you sure you've got the right attribute name for datatype? [19:12:00] Because if datatype is omitted, it defaults to a string... [19:12:05] <_jpl_> Does it matter at all how the property is defined in the component definition? [19:12:25] And there'd be no warning or error for that. [19:12:33] <_jpl_> Oops... [19:13:03] <_jpl_> In this particular sectiontype I used "type=" rather than "datatype="... argh. [19:13:10] There you go. [19:15:52] <_jpl_> So when using ZConfig to set properties, should I define them in the class with binding.requireBinding, or does it matter? [19:17:17] You need to define them with *some* kind of binding. [19:17:35] Anything that takes an offerAs=[] keyword. [19:17:49] If there's no reasonable default value, use requireBinding. [19:18:00] If there's a reasonable default, you might use binding.Constant. [19:18:24] http://peak.telecommunity.com/DevGuide/TwistedPeak I posted the example there. [19:18:26] If you want the value to be acquired unless explicitly set, use binding.Acquire. [19:18:31] And so on. [19:20:31] <_jpl_> nod. [19:20:51] <_jpl_> binding.Constant might be a little confusing, though. [19:21:01] How so? [19:21:08] <_jpl_> At least when I think of a constant I think of something that's not supposed to be changed. [19:21:44] Jolby (and everybody): could you please sign anything you do in the Wiki, so it's clear who's saying what? [19:22:43] Oh, sorry. I'm pretty much a Wiki (authoring) newbie. How do I sign it? Do I need to setup a personal page first? [19:22:56] No, just put your name on it. [19:23:07] Personal pages are nice, but optional. [19:23:11] I'll do that now. [19:23:34] The main point is just that nobody confuses unofficial examples/advice/etc. with official ones. [19:24:00] right-- done. [19:24:10] yeah, just sign [19:24:49] i have a wiki with a few of my (notably not good) peak examples: randomthoughts.vandorp.ca/moinmoin/index.html [19:24:49] <_jpl_> Which is why I was thinking it might need some sort of repurposing, or at least moving the existing DevGuide down a level. [19:34:58] pje: Just finished reading the zcml schema thread on zope3-dev. So it looks like they may add support for schema extension. If they did that, what, if anything, would I have to put in the EchoSchema.xml file? I was able to cut out everything but the multisection element at the end (and the two import elements) [19:36:40] It's NOT ZCML. [19:37:03] ZCML is something completely, utterly, and altogether different, and it is entirely unrelated. [19:37:54] Anyway... what you'd be able to do is cut out everything. [19:38:09] LOL! sorry man-- If you hit my head with something enough times it will eventually sink in.. :-) [19:38:22] Just have an empty block, with an extends='pkgfile:peak.running/EventDriven.xml' [19:38:39] with an for the new section type. [19:38:44] Ahh, got it. That would be more clear. [19:44:51] so is zcml a dead end, replaced by ZConfig? I used to see a lot of zcml stuff and I think I got it into my head that that was the "new" configuration markup language. [19:48:09] Jolby: no. [19:48:27] ZCML is for Zope X3, what peak.ini is for PEAK. [19:48:51] In the high-level sense, of being a tool for developers to hook things up, rather than for end users to configure things. [19:51:08] k. I'll try to keep that straight in my head. [20:02:00] * jack-e|dinner is gone (10:02PM): .. autoaway .. [20:06:07] Yeeha... Got a CGI/FastCGI demo example working in CVS now. [20:15:14] <_jpl_> Great! [20:19:50] pje: how do i test the cgi ? [20:20:06] --- jack-e|dinner is now known as jack-e [20:20:50] i tried ./trivial.cgi and peak CGI import:the_cgi:DemoCGI .. none works [20:21:06] Hm. [20:21:14] Here's what I'm actually using to run it: [20:21:49] #!/bin/sh -login [20:21:49] export PYTHONPATH=#blah#/PEAK/src:#blah#/PEAK/examples/trivial_cgi [20:21:49] exec peak CGI import:the_cgi.DemoCGI [20:22:02] Where #blah# is the location of my PEAK install. [20:22:04] err it put one ":" too much [20:22:09] in my peak command [20:22:24] The above three lines are the actual CGI script. [20:22:35] And it works for me as either a CGI or FastCGI. [20:23:13] ok .. so i need to update the python-path even when i'm in the examples/trivial_cgi dir ?? [20:23:25] You might want to cvs upd now, btw... I just checked in some changes. [20:23:42] Er, I dunno... I'm not running it that way. [20:23:51] That is #blah# isn't under my document root. [20:24:47] Note, by the way, that this is a pure CGI demo... it doesn't do any peak.web stuff whatsoever. [20:25:14] ok [20:25:40] peak.web's CGIPublisher is a CGI component like DemoCGI - but adds in the zope.publisher, peak.security, and peak.web stuff. [20:25:49] Did you get it to work? [20:26:31] yup .. i changed the invoke to use the absolute path and set the PYTHONPATH to the trivial_cgi-dir [20:32:17] Cool. I'm writing up a README now, and making a better trivial.cgi starter file. [20:32:42] * jack-e is looking forward to serve his first page with peak soon ... [20:32:49] (web-page) [20:38:20] Okay, README is in. [20:39:29] Next, I want to see if I can create a trivial peak.web app... [20:42:58] If it works, I'll be quite astonished. :) [20:43:05] :) [20:45:48] Oh, now that's weird... [20:45:55] I get "Unauthorized". Hm. [20:46:10] Well, that means it *sort of* works. ;) [20:46:35] It just works wrongly. :) [20:46:48] hihi [20:47:17] i've had lot's of "forbidden attributes" when was coding in zope3 :) [20:47:29] * pje nods [20:48:23] Is there any way to get zope.publisher to give a more helpful error message? [20:48:38] E.g. traceback and error value? [20:49:30] hmm .. they catch the errors somehow and put them into the error-log now - zope.exception i think) [20:52:32] Hmm... well, it's not going to stderr... [20:53:04] have you looked at the ZopePublication.handleException method ?? [20:56:14] src/zope/app/publication/zopepublication.py -> def handleException and src/zope/app/services/error.py -> def raising [20:56:31] these parts handle all error-logging and also printing to stdout if configured [20:56:55] the publisher calls publication.handleException when an error occurred [20:58:00] I added a traceback.print_exc to the default handleException in BaseInteraction. [20:58:20] And found the trouble... my trivial app didn't have a 'user' in its interaction, so security checks failed. [20:58:34] sounds right somehow .. [20:58:37] So, now I've got it working. [20:58:44] ql :)) [20:58:49] QL? [20:58:55] Oh, cool. [20:58:58] yup [20:59:27] * jack-e tries to configure apache to run a cgi with mod_fastcgi ... [21:02:08] so in terms of fastcgi .. is peak CGI static or dynamic ?? [21:02:30] it's not external .. afaics [21:03:44] Not external, no. [21:03:52] I'm using dynamic... [21:03:57] IIRC, anyway. [21:04:08] Specifically, you don't configure it hardwired in httpd.conf... [21:04:16] I just use SetHandler in .htaccess. [21:06:36] ok .. i'll try that [21:09:14] --> pyniac has joined #peak [21:13:39] Woohoo... [21:13:50] from peak.api import * [21:13:50] class AnonInteraction(web.BaseInteraction): [21:13:50] user = None [21:13:50] def getDefaultTraversal(self, request, ob): [21:13:50] if adapt(ob.getObject(), self.behaviorProtocol, None) is not None: [21:13:51] # object is renderable, no need for further traversal [21:13:53] return ob, () [21:13:55] # Not renderable, try for 'index_html' [21:13:57] return ob, ('index_html',) [21:13:59] class WebApp(binding.Component): [21:14:01] security.allow( [21:14:03] index_html = [security.Anybody] [21:14:05] ) [21:14:07] def index_html(self): [21:14:09] return "Hello world!" [21:14:11] interactionClass = binding.Constant(AnonInteraction, offerAs=[web.INTERACTION_CLASS]) [21:14:13] The world's first peak.web application. :) [21:14:22] congrats :) [21:14:27] Complete with 'index_html' handling. [21:14:48] I'm running it with 'peak CGI import:the_cgi.WebApp'. [21:15:05] fine [21:22:01] fastcgi works for me as well .. [21:22:29] so i'll need to do some office stuff (the real work) that i can finish .. it's fairly late again today .. [21:23:13] * pje nods. [21:23:31] I'm actually pretty happy with how much I've gotten done so far today. [21:23:49] * pje just checked in the trivial 'peak.web' example [21:24:15] fine .. i'll try that and then i'm off .. cu soon [21:27:52] <-- pyniac has quit #peak [21:44:39] ok, cool. Making progress. I extended the echo example to have a second Echo protocol that takes a ZConfig param that it prepends to each echo reply. Both of them start up and listen on different ports. [21:48:41] Great. [22:03:44] Ok, my next step would be to grab some other component (utility?) from w/ in the EchoProtocol object. a logging component would be a good start and a common use-case for a lot of folks. [22:04:12] pje: do you have any example apps that use ZConfig to set up a log object? [22:04:25] or would I even use ZConfig to do that? [22:05:08] At some point it'd be nice to have a ZConfig schema for logging... but I haven't designed one yet. [22:05:38] Right now I just use .ini, especially since it's something a site admin might want to set in the sitewide PEAK_CONFIG. [22:08:24] hmmmm... are .ini and ZConfig files meant to be used together? [22:08:56] for top-level config I mean... [22:09:42] Well, there's lots of ways to skin a cat. :) [22:09:58] First, 'peak.ini' is always loaded, which means PEAK_CONFIG is always loaded (if set) [22:10:14] Also, you can have an .ini file that acts as an interpreter to run a ZConfig file... [22:10:31] Or vice versa, for that matter, although the reverse takes more work to set up. [22:10:41] (Everything with ZConfig takes more work to set up.) :) [22:11:21] yes-- I notice that w/ ZConfig as well. reminds me of editing ejb-jar.xml files ... shudder. [22:12:21] Well, ZConfig really is for when you're packaging up your application for an end-user to use, not when you're developing it. [22:12:44] It's really easier, as a developer, to just write class statements to create your app structure when developing and testing. [22:12:58] so it sounds like the easiest route would be to have an echoserver.ini file that sets the logging stuff, and slurps the existing .zcfg file? [22:13:44] You could do that... or you could just encourage people to set PEAK_CONFIG and configure logging there, if they need it. [22:14:01] The default config is similar to PEP 282 logging: write warnings and above to stderr. [22:15:16] PEAK_CONFIG is the site-wide env variable pointing to your site .ini file right? [22:16:48] Yep. [22:17:10] It can actually list multiple .inis, separated by ':' (Unix) or ';' (Windows) [22:17:30] And it'll skip any non-existent files. [22:18:52] Ok, well for a self-contained example app, I think it might be easier to understand to have the .ini file right there in the root dir of the app. Actually, I'm starting to get a multi-stage peak+twisted tutorial forming in my head. [22:21:03] First start off with the ultra-simple EventDriven Command object example. Then maybe add a couple ZConfig examples. Then start adding a few utilities or other components using an .ini file. Finally, mix in site-wide config defaults, and maybe some more complicated component examples (using database, ldap, for login, etc..) [22:22:59] Cool. So when will you have it all ready? ;) [22:25:34] Who knows when I'll have it *All* ready, but I could have the first couple stages done pretty soon. I could just do it on the wiki so more knowlegeable peak'ers can point out errors. The later stages I need to learn how do do first... :-) [22:27:04] So, do you have an example anywhere of calling (interpreting?) a ZConfig file from w/in an .ini file? [22:27:53] I found the log section in the peak.ini file, so I could just do something like that, but set the stream to a file. Doesn't look hard. [22:31:20] peak.running.app = importString('peak.running.commands.IniInterpreter') [22:31:25] I think that would do it... [22:31:35] Whoops. sorry... [22:32:01] peak.running.app = naming.lookup(forObj,'zconfig.schema:path/to/theSchema.xml') [22:32:21] So then you set the #! line in the ZConfig file to point to the .ini file... [22:32:49] And the .ini file sets peak.running.app to load the schema as an interpreter for the ZConfig file. [22:33:29] what is the forObj in the naming.lookup(... method [22:33:38] <_jpl_> Could you set the Python path within that top-level .ini file? [22:33:39] ? [22:34:03] Jolby: forObj is available in .ini file rules, it's the object that the property was being looked up on. [22:34:15] _jpl_: was that Q to me? [22:34:18] JPL: no, you can't set the Python path in an .ini file, not easily anyway. [22:34:42] pje: so its automagically there? I don't have to set it anywhere? [22:35:28] Jolby: yes, it's automagically there. See in peak.ini for some examples. [22:35:59] Oops... it's 'targetObj', not 'forObj'. [22:35:59] k. thanks. I'm goig to try to get version4 of the example app to work. [22:36:12] I wonder if I should change it... all the API's call it 'forObj'. :( [22:36:21] pje: ok, thanks [22:36:35] pje: might cut some confusion if they're the same [22:37:13] Yep. I don't know how I managed to get it different in the first place... [22:38:02] pje: its sometimes pretty easy to have naming mismatches between config and code files [22:39:28] Yeah, but this mismatch is in the same file: peak.config.config_components. Ah well. [22:56:18] pje: I'm a little confused about the sequence you posted above about loading a ZConfig from an .ini file. In particular, won't the line: peak.running.app = naming.lookup(forObj,'zconfig.schema:path/to/theSchema.xml') [22:56:31] just give you a schema object? [22:56:47] not an app instance? [22:56:56] Yes. [22:57:14] But the 'run()' method of a schema checks self.argv[1] to see what ZConfig file to load. :) [22:57:47] Hmm. ok. I'll try it out. [22:57:50] So, if you make the .ini file the #! interpreter of the ZConfig file... it will get the ZConfig file as its argv[1]. [22:58:28] i.e., if 'myapp.zcfg' begins with #!invoke myapp.ini [22:58:45] And 'myapp.ini' begins with #!invoke peak runIni [22:59:18] Then running 'myapp.zcfg' is equivalent at that point to 'peak runIni myapp.ini myapp.zcfg' [22:59:41] Make sense yet? [23:02:00] whew-- sort of. that's a lot of files pointing at each other. Actually, this probably wouldn't be that hard, except, I have the problem of not really being able to use #!./invoke as we found earlier. [23:02:54] I'm trying to create a .sh script that sets the path, then does the "peak runIni myapp.ini myapp.zcfg" construct. [23:03:06] Well, you can always put invoke in /bin, so it's just #!/bin/invoke [23:03:58] right-- but I still have the problem of the arguments sent to #!./invoke being limited to 128 chars. [23:04:15] Can't you just set PYTHONPATH in your .profile, though? [23:04:23] Its not invoke that's broken-- its my command shell. [23:04:46] <_jpl_> I'm leaning toward the shell script option myself. Since I need to set PYTHONPATH anyway, I also set PEAK_CONFIG and allow the user to pass in a ZConfig file as $1 if desired. [23:05:07] JPL: setting PEAK_CONFIG in an application is *not* recommended. [23:05:18] <_jpl_> This is in the shell script. [23:05:23] Remember, system administrators will want to have a sitewide config. [23:05:41] If you're appending to it, that's probably ok. [23:06:12] Or possibly prepending, depending on whether you want them to be able to override your settings. [23:06:27] <_jpl_> This will be the only PEAK-based app my users will use, so there's no chance of clobbering any other PEAK_CONFIG setting. [23:07:12] How do you know they won't download another PEAK-based app from somewhere else? ;) [23:07:22] Not much chance of it right this minute, I'll admit. :) [23:07:50] <_jpl_> I'm gonna roll the dice for now. :) [23:08:00] * pje shrugs [23:08:22] I suggest using PEAK_CONFIG=$PEAK_CONFIG:/whatever [23:08:22] pje: I'd like to avoid setting PYTHONPATH in .profile if at all possible because I play around with a few different versions of a bunch of libs/frameworks (zope, twisted, zodb, etc...) and they don't always play well together. [23:08:43] <_jpl_> I'll keep it in mind, though, since this will eventually (hopefully soon) be released as open source. [23:09:13] Jolby: why not make some shellscripts called 'withzope' 'withtwisted', etc. that append to PYTHONPATH and then exec $*? [23:09:29] So then you can say 'withzope withpeak myapp.zcfg' [23:09:38] * pje grins [23:09:46] <_jpl_> Nice :) [23:09:59] That could work. I'll give er a shot. Thanks. [23:10:12] * pje doesn't like typing any more than necessary [23:10:25] But I also don't like hardcoding PYTHONPATH in scripts... [23:10:35] ...because eventually it leads to even more typing. :) [23:10:41] And even worse, thinking! :) [23:11:15] nooooo, not thinking! [23:11:24] (the horror!) [23:11:34] Remember, the mind is a terrible thing. :) [23:11:55] lol! [23:12:24] In my case, I've had to deal with this sort of crud in that we had a bunch of "internal use" apps that did all this kind of environment setting... [23:12:41] And then somebody bought the apps, so we had to clean them up such that somebody else could install them... [23:13:05] And then we really couldn't have the scripts hardcode paths anywhere, because then we couldn't maintain them. [23:13:15] Because they needed to run for us *and* the customer. [23:13:27] And that is really how the concept of "executable configuration files" came about. [23:14:08] It allows us at the very least to bypass the issue of where the config files are, because that gets passed in via sys.argv. :) [23:15:02] Yeah-- I like it. [23:15:07] Granted, the way we've been doing things assumes that for our production and customer environs, everything will already be on the PYTHONPATH. [23:15:18] So there should be no PYTHONPATH setting at all in our production environs. [23:15:48] But I'm realizing from this discussion that that won't necessarily work in a heterogeneous application environment. [23:16:02] right-- but the with- * construct is great for the quicksand of a dev environment [23:16:40] You like that? I made that idea up fresh, just for you. :) [23:16:57] I'm just using 'PYTHONPATH=foo whatever' right now. [23:17:21] Usually because "foo in ('src', '.')" right now. :) [23:17:22] Thanks! :) [23:19:22] hey _jpl__ -- are you one of the folks working on MOM stuff in PEAK? I thought I saw jack-e and you discussing some MOM stuff, but I can't remember if that was you or not. [23:25:08] <_jpl_> I'm very interested in it, and will definitely contribute once we actually start doing something. [23:26:31] <_jpl_> It's not even vaporware at this point. :) [23:27:01] ok. sounds cool. I'm a couple weeks into a project writing a jabber server in twisted (and now I'm going to try to retrofit it using PEAK components). So maybe we can all collaborate on a messaging core. [23:27:43] <_jpl_> Excellent. Have you done anything with JEP-0060, or thought about it? [23:29:50] That's the pub/sub stuff right? No-- I've just been implementing jabber-core right now. I definitely do want to do pub/sub as well as bytestreams. [23:57:51] * pje is gonna head home now. [23:58:09] <_jpl_> See you later [23:59:41] adios [23:59:45] pje: bye-- thanks for all the help