[01:42:02] ** hazmat has left IRC (Read error: 110 (Connection timed out)) [01:43:09] ** hazmat has joined us [02:30:44] ** gpciceri has joined us [03:42:31] ** gbay has joined us [03:44:39] ** gpciceri has left IRC (Read error: 110 (Connection timed out)) [03:50:03] ** hazmat has left IRC (Read error: 60 (Operation timed out)) [03:54:36] ** gpciceri has joined us [04:03:54] [connected at Thu Apr 22 04:03:54 2004] [04:03:54] <> *** Looking up your hostname... [04:03:54] <> *** Checking ident [04:03:54] <> *** Found your hostname [04:04:25] <> *** No identd (auth) response [04:04:25] <> *** Your host is sterling.freenode.net[freebsd.widexs.nl/6667], running version dancer-ircd-1.0.35 [04:04:25] [I have joined #peak] [04:04:25] ** sterling.freenode.net set the topic to peak - Python Enterprise Application Toolkit | http://peak.telecommunity.com | alpha3 is out !!! [04:46:34] ** vlado has joined us [05:48:04] ** gpciceri has left IRC ("Client exiting") [06:33:40] jack-e|away is now known as jack-e [06:33:47] morning [06:45:23] ** gbay has left IRC ("It's not like I'm leaving or anything...") [07:00:24] ** vlado_ has joined us [07:00:26] ** vlado has left IRC (Read error: 104 (Connection reset by peer)) [08:24:51] ** rdmurray has joined us [08:24:51] ** rdmurray has left IRC (Client Quit) [08:25:53] ** rdmurray has joined us [08:26:02] ** rdmurray has left IRC (Client Quit) [08:26:17] ** rdmurray has joined us [08:26:42] ** rdmurray has left IRC (Client Quit) [08:27:32] ** rdmurray has joined us [09:37:12] ** sremington has joined us [11:16:01] ** vlado_ has left IRC (Read error: 104 (Connection reset by peer)) [11:16:16] ** vlado_ has joined us [11:19:08] what could be the cause for such an error: TypeError: cannot create weak reference to 'classobj' object ??? [11:19:47] i'm trying to fix peak.web's error handling .. and when a NotFoundError is raised, this error is masked by several try/except blocks [11:20:24] NotFoundError is an instance of class WebException(Exception) [11:51:55] ** vlado_ has left IRC ("Leaving") [12:25:03] ** pje has joined us [12:25:22] Classic classes aren't weak-referenceable. [13:01:41] hey phillip [13:02:47] i tried to fix the p.w.error handling [13:03:16] the WebException has a binding.Make Attribute but is not an ActiveClass .. so the template isn't correctly looked up [13:04:47] i split up the class WebException(Exception) into a WebException (trivial subclass of Exception) and WebExceptionFacade(binding.Component) that is an adapter from WebException to IWebException and provides access to the needed information and context [13:04:54] you want me to send a patch ? [13:06:44] No... try this instead: [13:06:52] template = binding.Make(template, attrName="template") [13:07:39] Although honestly I'm surprised it didn't detect the attribute name itself. [13:08:03] do binding.XXX methods now work on any class ? [13:08:48] They should. [13:08:58] They just don't give very helpful errors if there's an error. [13:09:09] However, they *have* to know their attribute name. [13:09:28] Actually, I just checked and it's not the attribute name that's breaking. [13:09:46] >>> WebException.template.attrName [13:09:46] 'template' [13:10:00] its one of several problems [13:10:18] TypeError: cannot create weak reference to 'classobj' object is the error i get then [13:10:34] Do you know what line that's in? [13:10:44] File "/usr/lib/python2.3/site-packages/peak/security/permission.py", line 305, in of [13:10:44] return self.__cache[protectedObjectType] [13:10:47] for NotFound [13:10:55] protectedObjectType == NotFound [13:11:34] Ah yes... that's a known issue: you can't declare permissions on classic classes. [13:11:40] That's the bit that really needs to get fixed. [13:11:43] and Exception is one ? [13:12:03] Yes. [13:12:15] And you can't have a proper exception object that's new-style, either. [13:12:17] ok .. so i have a "workaround" instead of a fix :) [13:12:49] Yeah, I think permissions should really be usable w/classic classes. [13:13:13] what if you just don't cache the lookups ? [13:13:32] I could also keep a separate cache. [13:13:48] if it's worth to do so .. [13:14:29] Permission lookups are a critical path for peak.web... every time you display something or traverse to something, you're doing permission lookups. [13:15:53] * jack-e is also trying to rip out the minimun needed from zope.publisher to work with twisted.http-server and has no dependencies on z3 (simple http-requests for now, not more) [13:16:02] OTOH, classic classes as permission targets may not be that critical. [13:16:24] I guess the quick fix would be a try/except TypeError: around the statement that's currently breaking. [13:17:00] within web/permissions/Permission::of ? [13:17:42] you need to fix the lookup and the setting of the cache within there [13:20:46] Yeah, that's what I'm saying the quickest fix for now would be. [13:20:48] yup .. these changes make it work finally (1. add attrName='template', 2. add TypeError at __cache lookup, 3. prevent __cache setting from raising a TypeError [13:20:55] ) [13:21:48] The only problem I see with ignoring the caching is that I think lookup rules will then fail. [13:22:30] (Because of the way classes compare to each other) [13:23:05] I think it'll end up being that I have to have two caches. [13:23:31] (In PermissionType) [13:24:12] The cache is intended to ensure that SomePermission.of(X) always returns the same object, as long as X still exists. [13:24:29] right .. that's true .. compared by identity won't work then [13:25:37] Although I suppose I could change the comparison and hash methods, so that it would still work. [13:25:50] Anyway, you can see why I haven't bothered tackling this as yet. :) [13:26:40] right .. but it's really hard to work with, if all the errors that you'ld like to see are masked by the error-reporting-machinery ;-) [13:27:37] btw. is there a way to replace/overwrite adapter declarations somehow ?? [13:39:05] ** gpciceri has joined us [13:39:40] No. [13:39:59] You have to define a new protocol (e.g. protocols.Variation), and use that protocol as the target instead. [13:40:05] gpciceri is now known as gpciceri|dinner [13:40:06] ok [14:04:07] <_jpl_> Hi all [14:07:19] Hey. [14:07:58] <_jpl_> Hi Phillip. [14:33:00] gpciceri|dinner is now known as gpciceri|bigbrot [14:36:55] ** hazmat has joined us [14:47:53] hey john :) .. how's junction coming along ? [14:52:57] <_jpl_> I started working on the start of a store-and-forward mechanism for pub/sub, but then had to do "real" work... [14:53:07] hehe [14:53:47] Gotta get to a meeting... later [14:53:48] ** pje has left IRC ("Client exiting") [14:57:00] <_jpl_> That's why I (thought I) needed subscribable lists, so that junction.publish() would create a message object (new) and give it to a publisher object, which would do the actually delivery. [14:58:57] how do you address the destination ? queue-name, client-id, ... ? [15:00:51] <_jpl_> Currently it's only by subject. Channels and recipients will come later. [15:01:32] so you directly subscribe to an eventsource (which represents the subject) ? [15:04:11] <_jpl_> That's how it will work once I peak.events-ify it. [15:05:20] <_jpl_> So then it will be possible to yield to a subscription, which would be really nice. [15:05:40] or Any(, , ..) [15:05:41] :))) [15:05:55] <_jpl_> Yeah, even nicer [15:05:57] and ... you have channels [15:06:02] sort of [15:06:13] <_jpl_> It's sortof like channels, yeah [15:06:42] <_jpl_> It's almost as good anyway. [15:07:12] how do you think you will "get to" the eventsource (lookup(uri) | getService('name').subscribe('xx') | ..) ? [15:07:24] <_jpl_> Though I'd like to add the possibility of subscribing by wildcard, so you could say junction.subscribe('foo.bar.*') [15:09:01] i think the subscriptions are the transport, more advanced services can be developed ontop of it [15:09:03] <_jpl_> Well, you wouldn't really subscribe to a service like that. At least the way I currently think of it a service is something you want to call methods on. [15:09:22] do you "configure" subscriptions ? [15:09:45] <_jpl_> No, you just do a junction.subscribe(topic) [15:09:51] ah .. ok [15:10:29] so you need to provide some logic for broadcasting the messages with your connectors .. right ? [15:10:36] <_jpl_> But, with services you should be able to wait until a certain service is available. [15:10:50] <_jpl_> Right, that logic is currently there and works pretty well. [15:11:05] i tried to build such a system .. but didn't have enough time to get really into it ... [15:11:18] ql [15:11:29] <_jpl_> It will need some serious tweaking though if Junction will ever support anything other than a hub configuration. [15:11:49] <_jpl_> e.g. multiple hubs, daisy-chaining, etc. [15:12:03] hub config = broadcast everything ? [15:12:27] or more like peer-to-pear [15:12:28] <_jpl_> Actually, I think daisy-chaining should already work... [15:12:56] <_jpl_> By a hub configuration I mean a single server which various clients connect to. [15:12:57] * jack-e hasn't really dived into junction yet [15:13:04] ok [15:13:25] <_jpl_> Currently in any instance of Junction you can have one inbound connection and one outbound [15:14:05] so how can you build a hub , if there's only one in/out [15:14:16] <_jpl_> The publish algorithm publishes to local subscribers first, then calls remote publish methods on the client (if any) and the server (if any). [15:14:54] <_jpl_> 10 clients talking to one server is a hub [15:14:56] <_jpl_> for example [15:15:37] <_jpl_> The server in the middle is the hub [15:15:38] ok .. so a client can only connect to one server .. right .. but one probably could connect servers (like irc) [15:16:19] <_jpl_> In theory, that's the idea [15:16:30] can a service invoke methods on a client ? [15:16:37] s/service/server [15:16:38] <_jpl_> An IRC connector would probably only support pub/sub, at least initially. [15:17:01] <_jpl_> Only certain types of connectors (like PB) can do that. [15:17:19] makes sense .. jabber might too [15:17:51] <_jpl_> So for something like IRC the connector on the client side would be watching the output stream for events. [15:18:02] it shoudn't be too hard to implement a jabber-connector ontop of twisted's implementation .. [15:18:08] <_jpl_> Jabber has a pub/sub spec I've been meaning to look at. [15:18:21] several specs afaik :) [15:18:33] <_jpl_> ach [15:18:56] but i'ld just use it as transport for now .. interoperablitiy can be builtin later [15:19:15] you don't have a pub/sub mechanism for other connectors anyway [15:19:44] <_jpl_> All we have at the moment is PB [15:19:54] <_jpl_> I might want to do CORBA next [15:19:58] eek [15:20:18] i worked with CORBA a bit as well .. but haven't really got far [15:20:25] <_jpl_> Then again, if I were going that route it would probably make more sense to just use cosNotification [15:20:27] what orb you use ?? omniORB ? [15:20:37] <_jpl_> ja, omniORB [15:20:47] * jack-e too [15:20:57] <_jpl_> I don't really use it though. :) [15:21:07] <_jpl_> I've only played with it so far. [15:21:33] if i find some time i might contribute the jabber-connector once .. [15:21:44] <_jpl_> Maybe XMLRPC and SOAP would be better for the next couple of connectors. [15:21:57] * jack-e still has slp integration on his todo list ... [15:22:10] simple for shure :) [15:22:13] <_jpl_> Yeah, me too, I really want that in Junction. [15:22:13] -h [15:22:44] <_jpl_> There's also a DNS-based mechanism for doing SLP-type service lookups. [15:22:55] <_jpl_> Twisted has basic support for it, but no docs. [15:23:03] iok [15:25:31] <_jpl_> Hmm, it just occurred to me that I could write a very simple lightweight protocol for Junction that wouldn't need any other libraries. [15:25:42] <_jpl_> It could be like a "native Junction" connector. [15:25:50] why bother ? [15:26:03] inventing new transports isn't a trivial thing i think [15:26:08] <_jpl_> Good question :) [15:26:29] Pyro, SPIRO, twisted.pb, ..... [15:26:45] * _jpl_ hasn't heard of SPIRO [15:27:01] i've read about it lately in freshmeat i think [15:27:09] yapyrpc [15:27:29] <_jpl_> Is it new? [15:27:58] yapyrpc == choke (YetAnotherPythonRPC) [15:28:05] -h (grr) [15:30:16] <_jpl_> hmm, it looks quite basic. [15:30:22] yeah [15:30:38] <_jpl_> Maybe peak.net could include yapyrpc :) [15:30:53] <_jpl_> Based on the PEAK reactor rather than Twisted [15:31:36] i don't see a reason to repeat all the work .. [15:32:04] i'm currently working on getting rid of z3 dependency for peak.web .. when it's used with twisted.http [15:32:11] <_jpl_> How well do you think PyRO would integrate with PEAK? [15:32:38] look in our cvs: -> libs/nll/src/nll/net/rpc/pyro ... [15:32:47] <_jpl_> So then you'd have the choice of using either zope.publisher or twisted.http? [15:33:04] you just lookup('pyro://uri').(args) [15:33:16] right [15:33:30] <_jpl_> nice [15:33:31] i have twisted.http running with peak.web (look at my peakplace sandbox [15:33:46] but it still uses zope.publisher to do the traversal ... [15:33:53] <_jpl_> Maybe you could contribute that pyro: handler to PEAK [15:34:14] that's what i'm trying to refactor out currently [15:35:02] i don't know how phillip thinks about pyro (/me remembers a discussion about mysql ;-) [15:36:47] i think it would make more sense to write a "native" pyro-connector for junction than to get pyro into peak [15:37:08] in this way you totaly hide the network-transports which is a good thing (tm) imho [15:37:27] <_jpl_> That's the idea [15:37:45] same as gnurpc for gnue.org .. [15:38:05] have you looked at it ? [15:39:51] <_jpl_> I've glanced at gnue.org before, but it always looked very "in progress" [15:39:58] yeah :) [15:42:17] <_jpl_> ah, their RPC idea looks a lot like Junction [15:42:25] jup [15:45:12] <_jpl_> Doesn't look there's much in gnue.common.rpc though, unless I'm reading the epydoc incorrectly. [15:45:32] last time i looked, they had xmlrpc implemented [15:46:10] <_jpl_> And their event mechanism looks pretty rudimentary. [15:47:48] <_jpl_> Looks like you have to subclass EventAware to use it [15:48:04] <_jpl_> Nothing like peak.events EventSources or Tasks [15:48:13] right [15:48:20] <_jpl_> but that's not surprising [15:48:25] :) [15:58:07] <_jpl_> Do you know if there's a way to use keepalive with XMLRPC? [15:58:20] no clue [16:00:03] <_jpl_> Probably wouldn't help anyway. There's probably no way of getting around the need for clients to accept incoming XMLRPC connections. [16:00:22] <_jpl_> It's not a two-way street like PB, as far as I know. [16:00:51] right .. except you have 2 connections .. bad for nat/firewalling [16:01:32] <_jpl_> yep [16:01:39] do you know how pb uses socket connections ?? only one from client -> server ?? [16:01:41] <_jpl_> SOAP can probably do it, though [16:01:54] <_jpl_> Right, only one socket (client->server) is needed for PB [16:01:59] good [16:02:13] <_jpl_> That's one of the reasons I went with it first [16:03:05] <_jpl_> Also the server can call methods on the client if you pass Referenceable when you login. [16:03:24] <_jpl_> s/pass Referenceable/pass a Referenceable/ [16:03:50] (which is a "proxy" to the local pb.server ?) [16:03:57] local == client [16:04:27] <_jpl_> No, it's any Referenceable object that lives on the client. [16:04:34] ok [16:04:41] <_jpl_> In Junction I call it a ClientController [16:04:51] <_jpl_> or something like that :) [16:05:11] <_jpl_> JunctionController [16:05:52] <_jpl_> But it's configurable, so in theory you could subclass JunctionController to add more remote-control capabilities to your clients. [16:06:17] vendor-extensions :) [16:06:19] <_jpl_> You'd then write a Junction service which acts as the front end for doing those extra things [16:06:44] <_jpl_> But in practice a lot of that can be done with pub/sub, I think [16:07:38] <_jpl_> You could have your clients subscribe to certain control topics, then do some work or reply with data when they get the message. [16:08:58] yup [16:09:10] <_jpl_> hmm, I wonder if Junction could/should just become a conduit for peak.events EventSources [16:09:37] <_jpl_> so, in theory, you could yield to a semaphore on some other machine, for example [16:09:53] :) [16:10:05] <_jpl_> sounds nice :) [16:10:12] go for it :)) [16:12:27] <_jpl_> Hmm, then the rest of Junction would basically be an apparatus for keeping a distributed registry for finding event sources [16:13:21] or providing higher level services on top of this ability [16:13:50] <_jpl_> in theory this shouldn't be hard... [16:15:46] <_jpl_> there could even be an adapter which wraps any IEventSource, thereby making it global [16:21:22] <_jpl_> adapt(source, IDistributedEventSource) [16:24:04] how would that work ? [16:24:40] like binding.Make(ES(), adaptTo=IDistributedEventSource) ? [16:30:14] <_jpl_> Possibly, if the adapter can find IJunction [16:30:42] ok [16:30:45] <_jpl_> I was thinking of junction.register(something, eventSource) [16:31:14] <_jpl_> Where "something" is the way in which the event source would be locatable [16:31:24] <_jpl_> which is "to be determined" :) [16:31:41] hehe [16:32:34] use urls and peak.naming (with that one can locate the sources/services with e.g. slp/ldap/... too) [16:32:41] <_jpl_> A message channel could work that way. Remote clients would simply subscribe or yield to it to get messages. [16:33:54] <_jpl_> But then a channel would have to be both an event source and an event sink. [16:34:17] this is possible afaik [16:34:39] <_jpl_> Yeah, event sinks are just any callable, iirc [16:50:33] <_jpl_> hmm, channels would have to live on a server in order to have any kind of efficiency [16:51:21] yup [16:52:04] <_jpl_> I was thinking you could just create a channel whenever, and the registry would keep track of its location [16:52:32] <_jpl_> But perhaps a ChannelService would be better [16:52:56] you usally configure available channels i think [16:52:59] <_jpl_> That way the user can decide where channel objects live [16:53:06] <_jpl_> Yeah, you do in JMS [16:56:35] ** sremington has left IRC ("Laugh while you can monkey boy!") [17:09:36] nite [17:09:40] jack-e is now known as jack-e|away [17:22:21] ** hazmat has left IRC (Read error: 60 (Operation timed out)) [17:24:41] ** gpciceri|bigbrot has left IRC ("Client exiting") [17:45:48] ** hazmat has joined us [17:47:25] <_jpl_> Actually, it does make sense to create a new protocol. When junction becomes completely message-based, all the other RPC-type mechanisms are overkill. [17:50:17] <_jpl_> Though the message will need to support arbitrary data as a payload, so marshalling/unmarshalling would be required, and RPC mechanisms already do that for free. [18:04:09] ** gbay has joined us [19:12:43] ** hazmat has left IRC (Connection timed out) [19:16:02] ** hazmat has joined us [21:01:17] ** gbay has left IRC ("It's not like I'm leaving or anything...")