beepy-devel Mailing List for BEEPy - a Python BEEP library
Status: Alpha
Brought to you by:
jpwarren
Menu
▾
▴
beepy-devel — BEEPy Developer List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(6) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
| 2004 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
(8) |
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(3) |
Apr
(4) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: Justin W. <dae...@ei...> - 2008-10-06 23:30:02
|
On Mon, 2008-10-06 at 12:14 -0700, Sam Roberts wrote: > On Thu, Oct 02, 2008 at 05:15:55PM -0700, Justin Warren wrote: > > On Thu, 2008-10-02 at 09:38 -0700, Sam Roberts wrote: > > > Justin, have you tried to use beepy to connect to any other BEEP > > > implementations yet? > > BEEPy is something I maintain in my spare time, along with other > > projects, and it's not the highest priority one. Sorry, but that's what > > you get with free stuff sometimes. I still have to pay my mortgage. > > In no way do I expect you to work for free for us, or anybody else. We > appreciate the code being made available. It didn't work, but we fixed > it faster than we would have been able to write it ourselves from > scratch. Thank you. > > That said, I think you might be putting yourself in a bad light by > claiming that BEEPy does BEEP, when your version won't communicate with > any other BEEP implementation! I'm really sorry the code is broken in this way, and I agree that it sucks that BEEPy doesn't interop with other implementations. I'm sure you appreciate some of the work involved with setting up an interop environment that can test the range of test cases available. > Half-dead projects are worse than dead. If you don't have time to > integrate, and you want final control over all changes, you will get > forked. If you have no time to maintain BEEPy, you might even be happy > with that. I think its rude to fork people's projects without giving > them a bit of a warning, though. It's not that I want final control, it's that I'm the only one with write access to the codebase. That can change. > You could consider making a devel branch, and just dumping our code in. > Then people would at least have the option of getting working code from > your repo, and it could be improved incrementally. That's what I'm trying to set up. There are some tricky parts here. Without fixing the test cases, there's no way of knowing that it is working code. I've got to have some way of determining if I've merged your patch bundle correctly, for a start. And if all the test cases are broken because they don't match the new code, anyone grabbing the code and trying to use the test cases will see them fail. That might put me in a bad light, too. Also, API changes will affect anyone else who's using the current version, and may have also patched bugs themselves, but never sent the bugfix to me. This may not be a big deal, but I'm sure you'd be upset if I didn't use your new API, right? What if I don't agree with the API decisions you've made? How do we resolve that? All the doco will need updating to match the new API. The example code, the HOWTOs, etc. That's how people new to the code learn to use it. If it's wrong, that immediately puts new users off. Why don't we band together to solve the problem? You guys have obviously got some expertise with the code, so would you be interested in being added as developers with the ability to update the BEEPy codebase? -- Justin Warren <dae...@ei...> |
|
From: Sam R. <sro...@wu...> - 2008-10-06 19:53:28
|
On Thu, Oct 02, 2008 at 05:15:55PM -0700, Justin Warren wrote: > On Thu, 2008-10-02 at 09:38 -0700, Sam Roberts wrote: > > Justin, have you tried to use beepy to connect to any other BEEP > > implementations yet? > BEEPy is something I maintain in my spare time, along with other > projects, and it's not the highest priority one. Sorry, but that's what > you get with free stuff sometimes. I still have to pay my mortgage. In no way do I expect you to work for free for us, or anybody else. We appreciate the code being made available. It didn't work, but we fixed it faster than we would have been able to write it ourselves from scratch. Thank you. That said, I think you might be putting yourself in a bad light by claiming that BEEPy does BEEP, when your version won't communicate with any other BEEP implementation! Half-dead projects are worse than dead. If you don't have time to integrate, and you want final control over all changes, you will get forked. If you have no time to maintain BEEPy, you might even be happy with that. I think its rude to fork people's projects without giving them a bit of a warning, though. You could consider making a devel branch, and just dumping our code in. Then people would at least have the option of getting working code from your repo, and it could be improved incrementally. Sam |
|
From: Justin W. <dae...@ei...> - 2008-10-03 00:36:38
|
On Thu, 2008-10-02 at 09:38 -0700, Sam Roberts wrote: > Justin, have you tried to use beepy to connect to any other BEEP > implementations yet? > > Its broken SEQ number handling prevents interop with beep4j and vortex, > for example. > > Those bugs are among the ones we fixed. > > Sorry the patch sucked, but to get good patches, you need to regularly > accept and integrate small patches, or else fix them yourself. Btw, it > deliberately modified the API, the old API had conceptual problems, > so the tests will need to rewritten. > > Since our last email, we'll also fixed some problems that caused beepy, > already not very fast, to slow to a crawl on large messages and suck > 100% CPU, and probably various other stuff. > > We don't want to maintain this fork ourselves indefinitely, so we'll > probably rename our code and post a new project to sourceforge some time > unless these changes get integrated. > > We're happy to answer questions about any areas of the patch we sent, > but I never heard back from you. Hi Sam, BEEPy is something I maintain in my spare time, along with other projects, and it's not the highest priority one. Sorry, but that's what you get with free stuff sometimes. I still have to pay my mortgage. I appreciate that you took the time to send me the patches. I started work on it, but it's not trivial to incorporate a big patch bundle like that. I've always accepted small patches, but I've received precious few. The fact that the tests haven't been updated means that not only do I have to incorporate the patch bundle, and inspect what it's changed to ensure I'm ok with it, but I also have to update all the tests. This increases the time it takes me to merge the code. If you could update the tests to exercise the code you've changed, that would go a long way to helping me incorporate your code. Otherwise, it's just going to take a while. I appreciate that this probably isn't what you wanted to hear. Having said that, I may well have some increased ability to work on the code in the near future, what with the holiday season approaching. Now that I know it's important to you, I'll bump it up in priority. -- Justin Warren <dae...@ei...> |
|
From: Sam R. <sro...@wu...> - 2008-10-02 16:54:49
|
Justin, have you tried to use beepy to connect to any other BEEP implementations yet? Its broken SEQ number handling prevents interop with beep4j and vortex, for example. Those bugs are among the ones we fixed. Sorry the patch sucked, but to get good patches, you need to regularly accept and integrate small patches, or else fix them yourself. Btw, it deliberately modified the API, the old API had conceptual problems, so the tests will need to rewritten. Since our last email, we'll also fixed some problems that caused beepy, already not very fast, to slow to a crawl on large messages and suck 100% CPU, and probably various other stuff. We don't want to maintain this fork ourselves indefinitely, so we'll probably rename our code and post a new project to sourceforge some time unless these changes get integrated. We're happy to answer questions about any areas of the patch we sent, but I never heard back from you. Cheers, Sam |
|
From: Marshall R. <mr...@db...> - 2007-09-03 16:34:27
|
> I have now fixed the truncation problem, and re-released the code as > version 0.6.1. If you downloaded and attempted to use version 0.6, > please delete it and replace it with 0.6.1. thanks! > My thanks to Sam Roberts for bringing this to my attention. hi to sam. /mtr |
|
From: Justin W. <dae...@ei...> - 2007-09-03 08:09:23
|
Hi Everyone, The BEEPy 0.6 release was broken, due to a bug in the script I used to change the license notice in all the source files. It truncated a lot of them and rendered the release un-usable. Poor quality control on my part. I have now fixed the truncation problem, and re-released the code as version 0.6.1. If you downloaded and attempted to use version 0.6, please delete it and replace it with 0.6.1. My thanks to Sam Roberts for bringing this to my attention. -- Justin Warren <dae...@ei...> |
|
From: Marshall R. <mr...@db...> - 2007-07-29 03:15:34
|
> The long awaited re-licensed version of BEEPy under the MIT license > has > now been released. justin - many thanks! /mtr |
|
From: Justin W. <dae...@ei...> - 2007-07-28 05:46:53
|
Hi everyone, The long awaited re-licensed version of BEEPy under the MIT license has now been released. You can grab it from the usual place over at SourceForge via: http://sourceforge.net/project/showfiles.php?group_id=58978 Hopefully this will encourage more people to use BEEPy, and BEEP. Enjoy! -- Justin Warren <dae...@ei...> |
|
From: Justin W. <dae...@ei...> - 2007-06-23 00:01:24
|
On Fri, 2007-06-22 at 07:21 -0700, Shutter wrote: > Message body follows: > > Hello, > > I'm developing a distributed-server application right now, > and as I work through protocol stuff I keep just reinventing > BEEP. So I'd like to give BEEP a try. > > You expressed an interest in switching BEEPy to an MIT > license several months ago and I was just wondering if you > were still planning on doing that. I'd like to use BEEPy, > and I might use it as LGPL, but MIT would be easier to > manage even though I'd plan on sharing any improvements to > the code. The plan is to change the license to MIT, yes, I've just been busy with other projects and haven't sat down and done the tedious bits of updating all the license references. For the benefit of yourself, and others, consider this email as my official blessing for using BEEPy under an MIT license. I'll try to sort out the details for a version update reflecting the change soon. > Great work, by the way; I haven't played with it yet, but > BEEPy looks like something that would be fairly easy to plug > in and use. Thanks! -- Justin Warren <dae...@ei...> |
|
From: Justin W. <dae...@ei...> - 2006-10-27 02:51:14
|
On Thu, 2006-10-26 at 09:42 -0700, Gabe Wachob wrote: > Justin- > I think the move is a good one - definitely more pythonic ;-) > > Does beepy *require* twisted? If I'm writing an app and want to use > BEEPy, do I have to build my app as a twisted app? It would be nice if > I didn't have to.. I like twisted, but its not reallly called for in > many cases. To be honest, I don't know. :) I haven't used BEEPy in so long I'm not sure how much I kept the non-twisted code in step with the twisted code. Originally you could use it without twisted just fine, but I'm not certain any more. There have been a couple of people who've wanted to use BEEPy without twisted, so I'll see what I can do to make it possible if it isn't already. -- Justin Warren <dae...@ei...> |
|
From: Gabe W. <gw...@wa...> - 2006-10-26 16:42:40
|
Justin- I think the move is a good one - definitely more pythonic ;-) Does beepy *require* twisted? If I'm writing an app and want to use BEEPy, do I have to build my app as a twisted app? It would be nice if I didn't have to.. I like twisted, but its not reallly called for in many cases. -Gabe On 10/26/06, Justin Warren <dae...@ei...> wrote: > Hi folks, > > After some of the recent communication on the list, I've had a good hard > look at the current BEEPy license and thought about my original > intentions for the licensing. > > I believe I'd like to change the license for BEEPy from LGPL to the MIT > license to make the library more compatible with Python in general, the > Twisted framework (Hi guys), and other software. I think the LGPL, in > this instance, is too belaboured with legalese for people to easily > incorporate it into their software. BEEPy is a tiny little library that > really belongs inside a larger project like the Python standard library > or the twisted framework. > > Does anyone have any objections to relicensing BEEPy as MIT? > > I think the purposes of BEEPy, and BEEP in general, would be better > served by making access to a high level language library for BEEP more > accessible. Those Vortex guys, with their XML-RPC and everything, they > think they're so hot; well we'll show them! ;) > > More seriously, I've recently learned a lot about how the Twisted > framework really works, and I think I can fold some of that knowledge > into BEEPy. There are some serious brains at work over there at divmod, > and I'd like to take advantage of their great work. It's been a while > since I actively developed BEEPy, but I think I can make some useful > updates. > > I know this is an uber-low traffic list, but if anyone has any comments, > please speak up. I really do value your feedback; I'm not smart enough > to grok this stuff on my own. > > And thanks for still caring about BEEPy. :) > > -- > Justin Warren <dae...@ei...> > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > beepy-devel mailing list > bee...@li... > https://lists.sourceforge.net/lists/listinfo/beepy-devel > -- Gabe Wachob / gw...@wa... \ http://www.wachob.com CTO, Amsoft / gab...@am... \ http://www.amsoft.net |
|
From: Marshall R. <mr...@db...> - 2006-10-26 15:14:43
|
> More seriously, I've recently learned a lot about how the Twisted > framework really works, and I think I can fold some of that knowledge > into BEEPy. There are some serious brains at work over there at > divmod, > and I'd like to take advantage of their great work. It's been a while > since I actively developed BEEPy, but I think I can make some useful > updates. excellent. > I know this is an uber-low traffic list, but if anyone has any > comments, > please speak up. I really do value your feedback; I'm not smart enough > to grok this stuff on my own. > > And thanks for still caring about BEEPy. :) i think it would be good for you to proceed. /mtr |
|
From: Justin W. <dae...@ei...> - 2006-10-26 14:24:17
|
Hi folks, After some of the recent communication on the list, I've had a good hard look at the current BEEPy license and thought about my original intentions for the licensing. I believe I'd like to change the license for BEEPy from LGPL to the MIT license to make the library more compatible with Python in general, the Twisted framework (Hi guys), and other software. I think the LGPL, in this instance, is too belaboured with legalese for people to easily incorporate it into their software. BEEPy is a tiny little library that really belongs inside a larger project like the Python standard library or the twisted framework. Does anyone have any objections to relicensing BEEPy as MIT? I think the purposes of BEEPy, and BEEP in general, would be better served by making access to a high level language library for BEEP more accessible. Those Vortex guys, with their XML-RPC and everything, they think they're so hot; well we'll show them! ;) More seriously, I've recently learned a lot about how the Twisted framework really works, and I think I can fold some of that knowledge into BEEPy. There are some serious brains at work over there at divmod, and I'd like to take advantage of their great work. It's been a while since I actively developed BEEPy, but I think I can make some useful updates. I know this is an uber-low traffic list, but if anyone has any comments, please speak up. I really do value your feedback; I'm not smart enough to grok this stuff on my own. And thanks for still caring about BEEPy. :) -- Justin Warren <dae...@ei...> |
|
From: Ivan R. J. <ju...@mc...> - 2006-10-05 15:39:36
|
> Hi Ivan, > > I haven't been actively developing beepy for a while because > I don't have a direct personal need for it at the moment, and > the userbase has been pretty quiet about bugs or features. > That said, I'm happy to spend a bit of time improving it if > someone is using it and needs some work done on it. Well, it's open source, if I need it fixed up, I can do it :-). Mostly, I wanted to make sure the same functionality existed for BEEPy whether you used twisted or not, and that it works on windows. These are pretty simple tasks. Other than that I was considering building an application that used BEEPy. > beepy is LGPL, which is a pretty permissive license. What > aspects of the licensing are you finding problematic? The only difference is the clause that requires that you provide sources for the library if the user asks for them. But, in effect, to work with some large entities on collaborations (private companies) they have taken the stance that anything GPL or LGPL can't even be observed by their employees. The lawyers toss it out before it gets to them. So on many of my projects, where I work with these companies I have to use either BSD software or write my own. Clearly, I don't want to write my own if it's already done. The other argument would be that commercial adoption of the library usually revolves around a "proprietary value add" to the library (something the company did with/or to the library to make it valuable to customers). If this is something they did to the library, the LGPL mandates they give away what they consider their intellectual property. This hinders commercial adoption significantly. Anyhow, it's up to you, I'm not disagreeable about this, but I would like to integrated BEEPy into a large project I'm doing that would require it to be BSD. Hope things are going well; I wasn't sure I could track you down after a couple of years :-) --Ivan > I'm always open to persuasion, so feel free to plead your > case. Some active development would be good for beepy. > > -- > Justin Warren <dae...@ei...> > |
|
From: Justin W. <dae...@ei...> - 2006-10-05 00:27:17
|
On Thu, 2006-10-05 at 07:47 +0800, Andy Dent wrote: > On 05/10/2006, at 7:00 AM, Justin Warren wrote: > > > beepy is LGPL, which is a pretty permissive license. What aspects > > of the > > licensing are you finding problematic? > > Probably that LGPL becomes GPL unless code is dynamically linked so > unless he wants to wrap his entire Python distro somehow in a dylib, > beepy implies GPL as far as lawyers go. (Opinion from two different > intellectual property lawyers in two different employers over the > last 8 years.) > > Many people misunderstand LGPL and assume it is more permissive than > in reality. My experience of legal opinions is that they are highly specific to the individual circumstances under which they are given; indeed, reality and the law occasionally contradict one another. I will respectfully disagree with the general statement above, as far as it applies to beepy. My reading of Section 6 in particular leads me to a different view. However, it is not my intention to stifle people's ability to use the library. I originally intended for the library to be usable by anyone, but that if modifications to it were made, that everyone could benefit from them. Given the niche nature of beepy, and the passage of time, I am less concerned with forcing people to share than I once was; I would like to think that if someone did improve beepy significantly that they would want to share their work with others as I have shared mine with you. The BSD license has been proposed, which is essentially a free-for-all license. Does anyone have any other suggestions? Perhaps a Pythonic license of some kind? -- Justin Warren <dae...@ei...> |
|
From: Andy D. <de...@oo...> - 2006-10-04 23:46:51
|
On 05/10/2006, at 7:00 AM, Justin Warren wrote: > beepy is LGPL, which is a pretty permissive license. What aspects > of the > licensing are you finding problematic? Probably that LGPL becomes GPL unless code is dynamically linked so unless he wants to wrap his entire Python distro somehow in a dylib, beepy implies GPL as far as lawyers go. (Opinion from two different intellectual property lawyers in two different employers over the last 8 years.) Many people misunderstand LGPL and assume it is more permissive than in reality. |
|
From: Justin W. <dae...@ei...> - 2006-10-04 22:58:37
|
On Wed, 2006-10-04 at 14:48 -0600, Ivan R. Judson wrote: > > > > > Hi Justin, > > > > I'm wondering if you're still supporting/developing beepy. I > > have an interest in a couple of projects that could benefit > > from beepy, and I notice it has a few issues (4 bugs, test > > won't pass for me on windows, ssl not supported without twisted). > > > > I'd be happy to work on these, but I'd prefer to be working > > on software with a BSD or at least less restrictive license > > than LGPL or GPL. > > > > Any chance I can convince you to modify the license in > > exchange for a healthy dose of contribution? Hi Ivan, I haven't been actively developing beepy for a while because I don't have a direct personal need for it at the moment, and the userbase has been pretty quiet about bugs or features. That said, I'm happy to spend a bit of time improving it if someone is using it and needs some work done on it. beepy is LGPL, which is a pretty permissive license. What aspects of the licensing are you finding problematic? I'm always open to persuasion, so feel free to plead your case. Some active development would be good for beepy. -- Justin Warren <dae...@ei...> |
|
From: Justin W. <dae...@ei...> - 2005-05-16 05:50:05
|
On Fri, 2005-05-13 at 12:45 +0200, grunch crash wrote: > Hello! > > I use BEEPy 0.5 to write client that connects to a server. I > investigated exaple clients and wrote my own (similar to > 'echoclient'). I have following issue with 'reactor'. > > Once 'reactor' is started, it takes whole control of a main thread and > no direct interaction with client is possible. It only does things > that are defined in profile class (hard-coded) or when channel is > started (e.g. do something for specified period of time) - when some > communication event occurs. > What I need is to create connection to server and call some client's > method when I need it (I need to interact with my client). This is more of a twisted issue than a pure BEEPy one, but the gist is that you need to decide what kind of client interation you need. Twisted, and thus BEEPy, uses an asynchronous programming model. This essentially means that you create your client to respond to 'events' that are detected by the main reactor, which checks for various events (such as new data arriving on a network socket) and calls an appropriate action based on that event. It sounds like you want to be able to do something like send keyboard input to the remote server when you hit enter, but to display as output any data received from the remote server whenever it's received. You would need to add keyboard interaction code that is called as part of the main reactor loop. This would then trigger the data sending methods when the user hits enter, for example. There are lots of ways to do this. > Is it possible to do this? Looking at 'EchoClient' (not 'echoclient') > exaple (that I guess works only with BEEPy 0.3 library) I think that > it was possible and with BEEPy 0.5 is not. Maybe there is a way to > 'not to use' reactor. EchoClient is defunct and has been removed from the current codebase. echoclient is the current code. I think you do actually want to use reactor, you just need to wrap your mind around how this affects your code. That said, it's a good idea for an example, since this is a pretty common programming task. I'll look into adding an example keyboard interactive program. -- Justin Warren <dae...@ei...> |
|
From: grunch c. <arr...@gm...> - 2005-05-13 11:32:48
|
Hello! I use BEEPy 0.5 to write client that connects to a server. I investigated exaple clients and wrote my own (similar to 'echoclient'). I have following issue with 'reactor'. Once 'reactor' is started, it takes whole control of a main thread and no direct interaction with client is possible. It only does things that are defined in profile class (hard-coded) or when channel is started (e.g. do something for specified period of time) - when some communication event occurs. What I need is to create connection to server and call some client's method when I need it (I need to interact with my client). Is it possible to do this? Looking at 'EchoClient' (not 'echoclient') exaple (that I guess works only with BEEPy 0.3 library) I think that it was possible and with BEEPy 0.5 is not. Maybe there is a way to 'not to use' reactor. Please help! Karol Ilow |
|
From: grunch c. <arr...@gm...> - 2005-05-13 10:45:12
|
Hello! I use BEEPy 0.5 to write client that connects to a server. I investigated exaple clients and wrote my own (similar to 'echoclient'). I have following issue with 'reactor'. Once 'reactor' is started, it takes whole control of a main thread and no direct interaction with client is possible. It only does things that are defined in profile class (hard-coded) or when channel is started (e.g. do something for specified period of time) - when some communication event occurs. What I need is to create connection to server and call some client's method when I need it (I need to interact with my client). Is it possible to do this? Looking at 'EchoClient' (not 'echoclient') exaple (that I guess works only with BEEPy 0.3 library) I think that it was possible and with BEEPy 0.5 is not. Maybe there is a way to 'not to use' reactor. Please help! Karol Ilow |
|
From: Justin W. <dae...@ei...> - 2005-04-17 23:29:28
|
On Sun, 2005-04-17 at 11:29 -0600, Pete Siemsen wrote: > Justin, > > I just noticed that when I go to > > http://beepy.eigenmagic.com/ > > ... I get a page about Zope. Thought you'd like to fix it. I found the > above URL by Google-searching for "beepy" and finding > http://beepy.sourceforge.net/, which contains a link to the above URL. Ah, ok. I'd better put something back up then. I killed the weblog because it wasn't getting updated and didn't really have much useful information on it. -- Justin Warren <dae...@ei...> |
|
From: Pete S. <si...@uc...> - 2005-04-17 17:30:06
|
Justin,
I just noticed that when I go to
http://beepy.eigenmagic.com/
... I get a page about Zope. Thought you'd like to fix it. I found the
above URL by Google-searching for "beepy" and finding
http://beepy.sourceforge.net/, which contains a link to the above URL.
-- Pete
|
|
From: Pete S. <si...@uc...> - 2005-04-11 17:51:51
|
I'm trying to get a JAVA client talking to a Python server using BEEP.
I have the demo BEEPy echo client and server working, and I have the
demo JAVA beepcore echo client and server working. I've made my own
versions of the Java client and the Python server, and I'm having
trouble getting them to talk to each other.
I start my Python server, and it outputs this:
npad$ twistd -ny npad-server.py
2005/04/11 11:00 MDT [-] Log opened.
2005/04/11 11:00 MDT [-] twistd 1.3.0rc1 (/usr/bin/python2.3 2.3.5) starting up
2005/04/11 11:00 MDT [-] reactor class: twisted.internet.default.SelectReactor
2005/04/11 11:00 MDT [-] Loading npad-server.py...
2005/04/11 11:00 MDT [-] <string> INFO: npad-server starting
2005/04/11 11:00 MDT [-] <string> DEBUG: instantiating a BeepServerFactory
2005/04/11 11:00 MDT [-] <string> DEBUG: setting the factory's profile to npadprofile
2005/04/11 11:00 MDT [-] <string> DEBUG: establishing a BEEP Listener on port 1976
2005/04/11 11:00 MDT [-] <string> INFO: npad-server exiting
2005/04/11 11:00 MDT [-] Loaded.
2005/04/11 11:00 MDT [-] beepy.transports.tcp.BeepServerFactory starting on 1976
2005/04/11 11:00 MDT [-] Starting factory <beepy.transports.tcp.BeepServerFactory instance at 0xb7a7d6ac>
2005/04/11 11:00 MDT [-] set uid/gid 5462/96
It's waiting patiently. I had a struggle figuring out how to get log
messages from the Java beepcore code, but I finally did. With the
Python server running, my Java client outputs this:
npad$ java edu/ucar/scd/nets/npad/NpadClient -port 1976 localhost
0 [main] INFO npad.NpadClient - Apache Jakarta Commons Logging initialized, using Log4JCategoryLog
75 [main] INFO edu.ucar.scd.nets.npad.NpadClient - Parsing command-line arguments
76 [main] INFO edu.ucar.scd.nets.npad.NpadClient - Initiating a TCP session with the server on localhost:1976
544 [main] DEBUG org.beepcore.beep.transport.tcp.TCPSession - sendGreeting
550 [main] DEBUG org.beepcore.beep.core.Frame - RPY 0 0 . 0 59
553 [main] DEBUG org.beepcore.beep.transport.tcp.TCPSession - Wrote the following
RPY 0 0 . 0 59
Content-Type: application/beep+xml
<greeting></greeting>END
553 [main] DEBUG org.beepcore.beep.transport.tcp.TCPSession - State changed to 1
555 [TCPSession Thread #0] DEBUG org.beepcore.beep.transport.tcp.TCPSession - Processing next frame
556 [TCPSession Thread #0] DEBUG org.beepcore.beep.transport.tcp.TCPSession - RPY 0 0 . 0 114
558 [TCPSession Thread #0] DEBUG org.beepcore.beep.transport.tcp.TCPSession - Content-Type: application/beep+xml
<greeting>
<profile uri="http://npad.ucar.edu/profile"/>
</greeting>
559 [TCPSession Thread #0] DEBUG org.beepcore.beep.core.ChannelImpl - Channel::postFrame
561 [TCPSession Thread #0] DEBUG org.beepcore.beep.core.ChannelImpl - Notifying reply listener.=>org.beepcore.beep.core.SessionImpl$GreetingListener@1ef9157
564 [TCPSession Thread #0] DEBUG org.beepcore.beep.core.ChannelImpl - Freed up 114 bytes on channel 0
564 [TCPSession Thread #0] DEBUG org.beepcore.beep.core.ChannelImpl - recvWindowUsed = 114 recvWindowFreed = 114 recvWindowSize = 4096
565 [TCPSession Thread #0] DEBUG org.beepcore.beep.transport.tcp.TCPSession - Wrote: SEQ 0 114 4096
566 [TCPSession Thread #0] ERROR org.beepcore.beep.transport.tcp.TCPSession - Problem with RPY: Invalid content type for this message
567 [TCPSession Thread #0] DEBUG org.beepcore.beep.transport.tcp.TCPSession - State changed to 8
569 [TCPSession Thread #0] DEBUG org.beepcore.beep.transport.tcp.TCPSession - Session listener thread exiting. State = 8
NpadClient: Error connecting to localhost:1976
Greeting exchange failed
npad$
...and the Python server logged only
2005/04/11 11:00 MDT [BeepServerProtocol,0,127.0.0.1] Failure: twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion.
So the client sent an empty greeting, the server responded with a
profile, and then the client died. The client failed inside the
beepcore TCPSessionCreator.initiate function, before it tried to open a
channel. I confess I don't quite understand the details of profiles and
URIs yet, but I think this problem is happening before profile selection
happens.
Help!
At the least, can I turn on more logging in the BEEPy code, so I can see
more of what's happening? It'd be nice to see logs of the greeting
exchange.
-- Pete
|
|
From: Justin W. <dae...@ei...> - 2005-04-01 03:13:26
|
On Wed, 2005-03-30 at 13:45 -0600, James Saker wrote: > New release? Yea! Thanks for the good news Justin. I've been trying to get it out for a while. Stupid life stuff keeps getting in the way. :) -- Justin Warren <dae...@ei...> |
|
From: James S. <jam...@fi...> - 2005-03-30 19:46:21
|
New release? Yea! Thanks for the good news Justin. I'm continuing to try to get BEEPy working with a Reliable Syslog cooked profile. Have a raw profile (easy) working, but am way over my head in XML-land. Has anyone else on the list tried implementing BEEPy for RFC 3195 (available on beepcore.org here: http://www.beepcore.org/docs/rfc3195.html )? The raw implementation I've hacked together uses Justin's SASL authentication example. As the Cooked profile specifies relays (path element) and a few other complexities, I haven't made much progress as I've had to delve into XML. I have put together the package for a BSD syslog to reliable (raw only) relay which would be tremendously handy for administering numerous old syslog devices remotely. Since BSD syslog is UDP based, it suffers from reliability and authenticity issues (easily spoofed), and also is not useful for relaying security syslog messages over insecure networks. I've been tempted to bypass my BEEPy/reliable difficulties and just XML-RPC or another mechanism, but then I'd be ignoring the value of RFC 3195. Jamie Omaha NE >> I'm running Debian Linux "testing" with Python 2.3. >Cool. That's basically the same distro that I run. Running mostly 2.3 (with one workstation with 2.4) on Gentoo distribution, with Pax/GrSecurity hardened 2.6 kernel myself. > I'm trying to get the BEEPy echo client/server working. I've installed > BEEPy 0.5 and twisted. I wasted some time with EchoServer.py, then read > the beepy-devel archive, and I'm now working with echoserver.py. Please > delete EchoServer.yp and EchoClient.py from the distribution. This has been removed from CVS and I've cleaned up a bunch of similar things in preparation for a new release Real Soon Now. > Thank you so much for the excellent contents of the HOWTO file. Very, > very helpful! I think it has a minor glitch, where it mentions > "processFrame" when it means "processMessage". Thanks! I'll check it out. I've made some changes to the demo code due to some modifications to the API for 0.6, so this might have already been picked up. > I'm able to run echoserver.py as documented, but I can't run the > echoclient on the same machine, while echoserver.py is running. Twistd > complains that an instance is already running. Is there a way around > this? Ah, this isn't obvious from the HOWTO. The client doesn't run as a twistd file, rather you just run it as a python script, eg: python echoclient.py as the demo client uses the reactor directly, rather than as a twisted application. In general, though, twistd checks for the existence of a PID file, which it will create in the current directory by default. To run multiple twistd instances, use the --pidfile parameter to specify a new pidfile for each twistd instance. -- Justin Warren <dae...@ei...> ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ beepy-devel mailing list bee...@li... https://lists.sourceforge.net/lists/listinfo/beepy-devel |
1 message has been excluded from this view by a project administrator.
