Menu
▾
▴
pybeep-devel — Developer List
You can subscribe to this list here.
| 2002 |
Jan
(9) |
Feb
(5) |
Mar
(13) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gabe W. <gw...@wa...> - 2002-05-26 18:40:47
|
It was pointed out to me that SEDA [1] might not be a great advantage in Python given Python's global interpreter lock and the way it switches between threads (ie every ten bytecodes) [2]. I've been thinking about this a bit and I've decided that we should move forward with a SEDA-based implementation for the following reasons: 1) I think there is still an advantage for non-os threads or even the GIL situation in python w/r/t tuning of threads under heavy load, as well as debugging and monitoring (and unit testing, btw!!!) 2) There is always Stackless Python which may have interesting interactions with SEDA on its own 3) If this is done right, most of the coding will be event-handlers which means that the threading model can be SEDA, single (or fixed number) threads, or even fully multithreaded. And it should be *pluggable* (ie configurable at runtime). Thats actually quite cool,if one thinks about it. 4) Profile implementations are going to be implemented with event handlers no matter what anyway, and functionality exposed by the library will be exposed through an API which will hide any event-architecture specifics. Thoughts are *greatly* welcomed, though I expect work to commence quite soon on the event architecture refactoring. I think this will speed up development quite a bit, and will make both unit and functional testing much easier. -Gabe [1] http://www.cs.berkeley.edu/~mdw/proj/seda/ [2] http://www.python.org/doc/current/api/threads.html On Fri, 24 May 2002, Gabe Wachob wrote: > > I checked in the beginning of a SEDA-inspired framework today (in > lib/seda.py) > > It sorta actually works. Doesn't do everything SEDA yet - and it does a > polling to manage threads (which sucks - should be event based itself). > Also, "Stages" can only have one incoming sink (which might be all we need > for pybeep). > > Take a look. Its far from tested... > > -Gabe > > -- Gabe Wachob gw...@wa... Personal http://www.wachob.com Founder, WiredObjects http://www.wiredobjects.com |
|
From: Gabe W. <gw...@wa...> - 2002-05-24 23:20:54
|
I checked in the beginning of a SEDA-inspired framework today (in lib/seda.py) It sorta actually works. Doesn't do everything SEDA yet - and it does a polling to manage threads (which sucks - should be event based itself). Also, "Stages" can only have one incoming sink (which might be all we need for pybeep). Take a look. Its far from tested... -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com Founder, WiredObjects http://www.wiredobjects.com |
|
From: Gabe W. <gw...@wa...> - 2002-05-23 06:48:50
|
I put together some new documentation on how the beep library *could* be broken down into events. Please take a look and give me feedback. While I doubt that pybeep will end up strictly decomposing along these lines, this sort of deomposition already has me thinking more clearly about some abstractions. I think this document could be useful to other BEEP implementers as well. The files are events.xls and events.htm under the doc directory.. Shortcuts: HTML -> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/pybeep/beep/doc/events.htm?rev=HEAD&content-type=text/html XLS -> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/pybeep/beep/doc/events.xls?rev=HEAD&content-type=text/plain Sean and I have been working on other things (including finding work, working on a BEEP chapter in a forthcoming book, etc) and pybeep development has slowed quite a bit. However, work has not stopped!! We are always looking for others to become more actively involved! -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com Founder, WiredObjects http://www.wiredobjects.com |
|
From: Gabe W. <gw...@wa...> - 2002-03-15 20:17:59
|
I've used dia, but been really frustrated with it - has it gotten better recently? -Gabe On 15 Mar 2002, Sean Allen wrote: > On Fri, 2002-03-15 at 09:52, Gabe Wachob wrote: > > Dude, you rock. Haven't picked through the pic in detail, but it looks > > good from an initial glance. What tool did you use to make it? Also, can > > you check in both the png and whatever source file you have for this > > picture (ie from the tool) to the doc directory? > > K, they are in CVS. > > The tool is Dia, for GNOME, very cool, SVG Extensible open source > diagramming tool. > > Sean > -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-03-15 18:59:20
|
On Fri, 2002-03-15 at 09:52, Gabe Wachob wrote: > Dude, you rock. Haven't picked through the pic in detail, but it looks > good from an initial glance. What tool did you use to make it? Also, can > you check in both the png and whatever source file you have for this > picture (ie from the tool) to the doc directory? K, they are in CVS. The tool is Dia, for GNOME, very cool, SVG Extensible open source diagramming tool. Sean =20 |
|
From: Gabe W. <gw...@wa...> - 2002-03-11 17:14:54
|
Sean- I just committed some code (that doesn't work, but its been uncommitted so long - tests now break). Generally, I'm supportive of your plans - comments inline: On 11 Mar 2002, Sean Allen wrote: > Hi > > I started looking into the existing code-base to try and clean up some > of it this weekend. Sheesh. Hehe! Nobody said it was pretty. > I think, one of the next steps forward (and quite an important one) is > to decide what we don't want in the core anymore (eg. the datastream > stuff) and cut it out soon, as its really starting to get messy in > there. I'm loosing track of which stream I'm meant to be reading from. Yeah, thats a good idea. I think the only real cruft is the stream stuff (other than the DataQueueStream). I think your confusion is because the transition is not quite complete and the cruft has not yet been removed. We'll have to hook up on IRC so I can give you more details. As for unifying into one file - I'm all for that, but I had hoped to wait until the last minute so we could work on separate files so as to make CVS merging less frequent. At this point I'm really hestitant to push everything into one file. More comments inline... > My suggestion is also to begin to unify the core into a single namespace > (i.e one .py file), the reasoning for this is: > > 1) It's more natural. Absolutely!!! Before we have a 1.0 (or even .9) we *will* merge into a single module (file). > 2) it avoids multiple copies of stuff loaded into various namespaces. Yes, although I don't know where this is an issue with what we have. > I'm not advocating premature optimization, but it seems pointless to > have 5 copies of the same constant sprinkled out through 5 or 6 files I'm pretty sure we do *not* have the same constant defined in multiple places. At least we *shouldn't* - I tried to make sure that constants were syntactically contained in the module they related to but even then they shouldn't have naming conflicts (ie no constant should be defined in two modules). I've always had the plans to merge everything into one python module/file. > 3) It will be neater. Oh yeah!!! > Basically, core.py will be a large file,but I feel it will be easier to > manage and will only include the classes we need. We can also trim those > classe quite a bit(a lot of stuff in channel/session etc seems to be > Java specific and unnecessary). As for trimming - maybe. > What I am proposing is this. > 1) Trim and unify the core classes(Session, Channel, Message, Frame, > Scheduler etc.) into core.py, this would also mean dropping a few and > maybe moving the functionality into a single class (i.e. the > MessageStatus/Message issue) Actually messagestatus and message should be separate. I'm not sure there are any *classes* we should drop. Very likely some methods aren't neccesary. I've been focusing on getting functionality rather than prettiness. > 2) Unify utility classes (Synchronizable, a single Queue implementation > etc.) into a util.py OK, but why not in core.py? <plans niceness="evil" scale="world-domination"> I mean, ideally we're going to produce beep.py which will just go in the lib directory of the Python distro. </plans> > 3)leave the tests as is, but adapt them for new architecture (changing > imports basically) Yeah. > If nobody has any objections, I would like to work on this over the next > week, as it is, IMHO really necessary, it's getting hard to navigate the > source now. I agree the source is confusing, but I really don't want to smush quite yet. What I *do* want to do is the other stuff you mention (in particular) because it is confusing. I'll try to catch you on IRC tonight, if possible - we can discuss specifically what to do. Until then, if you'd like to compile a list of specific changes you want to make absent the smushing, that'd be a very useful specific list to discuss... -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-03-11 16:42:43
|
Hi I started looking into the existing code-base to try and clean up some of it this weekend. Sheesh. I think, one of the next steps forward (and quite an important one) is to decide what we don't want in the core anymore (eg. the datastream stuff) and cut it out soon, as its really starting to get messy in there. I'm loosing track of which stream I'm meant to be reading from. My suggestion is also to begin to unify the core into a single namespace (i.e one .py file), the reasoning for this is: 1) It's more natural. 2) it avoids multiple copies of stuff loaded into various namespaces. I'm not advocating premature optimization, but it seems pointless to have 5 copies of the same constant sprinkled out through 5 or 6 files 3) It will be neater.=20 Basically, core.py will be a large file,but I feel it will be easier to manage and will only include the classes we need. We can also trim those classe quite a bit(a lot of stuff in channel/session etc seems to be Java specific and unnecessary). What I am proposing is this. 1) Trim and unify the core classes(Session, Channel, Message, Frame, Scheduler etc.) into core.py, this would also mean dropping a few and maybe moving the functionality into a single class (i.e. the MessageStatus/Message issue)=20 2) Unify utility classes (Synchronizable, a single Queue implementation etc.) into a util.py 3)leave the tests as is, but adapt them for new architecture (changing imports basically) If nobody has any objections, I would like to work on this over the next week, as it is, IMHO really necessary, it's getting hard to navigate the source now. Sean=20 =20 |
|
From: Sean A. <ze...@wo...> - 2002-03-08 17:20:45
|
On Thu, 2002-03-07 at 19:24, Gabe Wachob wrote: > Answering my own question, please confirm: >=20 > It appears that MessageStatus is *just* for keeping track of which > messages have been sent for the purposes of verifying things like "does > this incoming RPY correspond to a previously sent outoing MSG?", and as > such, we need to keep the following information in a MessageStatus queued > up in sentMSGQueue: Thats kind of the way I read it too=20 > *status of the message (e.g. sent, responded, etc.. maybe we have to add > "queued, but not completely sent") >=20 > *replylistener (because someone needs to be handed replies to a particula= r > outgoing msg) >=20 > * msgno (for checking that a RPY/ANS/NUL received corresponds to the > oldest outgoing MSG not yet completley responded to) >=20 >=20 >=20 > I don't see any need for any other info in the MessageStatus, do you guys= ? >=20 > There is a slight twist - the channel only adds outgoing messages to a > queue to be written out. I'm thinking we should add two more states for a > message to be in (besides the 5 MESSAGE_STATUS_* there are now): >=20 > MESSAGE_STATUS_QUEUED -- its in the outgoing queue and no frames have bee= n > written out from it yet >=20 > MESSAGE_STATUS_PARTIALLY_SENT -- its in the outgoing queue and some frame= s > of the message have been sent out, but its not completely written out. >=20 > I actually don't know if we'll need to check for these states (they are > functionally equivalent to MESSAGE_STATUS_NOT_SENT, no?), but they will b= e > extremely useful for debugging and logging. >=20 > Make sense? Yes=20 Sean |
|
From: Huston <hu...@us...> - 2002-03-08 16:10:14
|
> It appears that MessageStatus is *just* for keeping track of which > messages have been sent for the purposes of verifying things like "does > this incoming RPY correspond to a previously sent outoing MSG?", and as > such, we need to keep the following information in a MessageStatus queued > up in sentMSGQueue: > > *status of the message (e.g. sent, responded, etc.. maybe we have to add > "queued, but not completely sent") > > *replylistener (because someone needs to be handed replies to a particular > outgoing msg) > > * msgno (for checking that a RPY/ANS/NUL received corresponds to the > oldest outgoing MSG not yet completley responded to) > > > I don't see any need for any other info in the MessageStatus, do you guys? I think we could get by with that. The only reason the other fields are there are for convienience. > There is a slight twist - the channel only adds outgoing messages to a > queue to be written out. I'm thinking we should add two more states for a > message to be in (besides the 5 MESSAGE_STATUS_* there are now): > > MESSAGE_STATUS_QUEUED -- its in the outgoing queue and no frames have been > written out from it yet > > MESSAGE_STATUS_PARTIALLY_SENT -- its in the outgoing queue and some frames > of the message have been sent out, but its not completely written out. > > I actually don't know if we'll need to check for these states (they are > functionally equivalent to MESSAGE_STATUS_NOT_SENT, no?), but they will be > extremely useful for debugging and logging. Sounds reasonable. --Huston |
|
From: Gabe W. <gw...@wa...> - 2002-03-08 03:24:27
|
Answering my own question, please confirm: It appears that MessageStatus is *just* for keeping track of which messages have been sent for the purposes of verifying things like "does this incoming RPY correspond to a previously sent outoing MSG?", and as such, we need to keep the following information in a MessageStatus queued up in sentMSGQueue: *status of the message (e.g. sent, responded, etc.. maybe we have to add "queued, but not completely sent") *replylistener (because someone needs to be handed replies to a particular outgoing msg) * msgno (for checking that a RPY/ANS/NUL received corresponds to the oldest outgoing MSG not yet completley responded to) I don't see any need for any other info in the MessageStatus, do you guys? There is a slight twist - the channel only adds outgoing messages to a queue to be written out. I'm thinking we should add two more states for a message to be in (besides the 5 MESSAGE_STATUS_* there are now): MESSAGE_STATUS_QUEUED -- its in the outgoing queue and no frames have been written out from it yet MESSAGE_STATUS_PARTIALLY_SENT -- its in the outgoing queue and some frames of the message have been sent out, but its not completely written out. I actually don't know if we'll need to check for these states (they are functionally equivalent to MESSAGE_STATUS_NOT_SENT, no?), but they will be extremely useful for debugging and logging. Make sense? -Gabe On Thu, 7 Mar 2002, Gabe Wachob wrote: > Guys- > Can someone remind me of why MessageStatus exists? It seems to add > a replylistener and status to a message, and then seems to (I believe in > error) associate separate channel, data, and answerno with the underlying > message. > > Is the MessageStatus cruft or what? I am going to whack it and > move everything into the Message unless I hear something very soon. I'm > trying to get channel to work, and mostly that means untangling sentToPeer > to work with my architecture. MessageStatus is deeply woven in there and > its time to figure out if we need it. > > -Gabe > > -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Gabe W. <gw...@wa...> - 2002-03-08 02:58:39
|
Guys- Can someone remind me of why MessageStatus exists? It seems to add a replylistener and status to a message, and then seems to (I believe in error) associate separate channel, data, and answerno with the underlying message. Is the MessageStatus cruft or what? I am going to whack it and move everything into the Message unless I hear something very soon. I'm trying to get channel to work, and mostly that means untangling sentToPeer to work with my architecture. MessageStatus is deeply woven in there and its time to figure out if we need it. -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Gabe W. <gw...@wa...> - 2002-03-01 19:24:26
|
As for the incrementalparser/read thing - I wouldn't do that - I would just pull BufferSegments off the "DataQueue" and feed their payloads directly to the IncrementalParser via feed. The use of read is just a bunch of extra overhead. feed appears to be a perfectly acceptable public method. -Gabe On 1 Mar 2002, Sean Allen wrote: > -----Forwarded Message----- > > From: Sean Allen <ze...@wo...> > To: Sean Allen <ze...@wo...> > Subject: Re: [Pybeep-devel] updates: scheduler and stuff > Date: 01 Mar 2002 11:17:10 -0800 > > On Fri, 2002-03-01 at 10:53, Gabe Wachob wrote: > > > Only two were broken and they were trivial fixes. Maybe this means we are > > behind on our test writing!!! > Yes, yes we are.... > > > I was hoping you'd volunteer! I'm a terribly messy coder and I really like > > having someone else's structure to work against. So please have at it.. > > just let me know what your style guidelines are. > > > I think a simple place to start here would be Guido's python style > guidelines.(http://python.sourceforge.net/peps/pep-0008.html) make sense > to work in a style used in the core libraries and I normally try to > follow these. > > > I was thinking the feed method on IncrementalParser (which just takes > > string data) would obviate the need for a file-like interface. If you > > look at the parse method, all it does is loop through the source parameter > > calling read and passing the results to feed anyway... and even so, the > > DataQueueStream has a read() method that would work just fine for parse (I > > think). > Ok.. cool, I'll look into this. So basically, we are going to work > around the read() method and use it for all our parsing needs... off to > the Incremental Parser source I go.... it was just throwing a wierd > exception at me when I was doing some interpreter testing the other day. > > Sean > -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-03-01 19:18:40
|
-----Forwarded Message----- From: Sean Allen <ze...@wo...> To: Sean Allen <ze...@wo...> Subject: Re: [Pybeep-devel] updates: scheduler and stuff Date: 01 Mar 2002 11:17:10 -0800 On Fri, 2002-03-01 at 10:53, Gabe Wachob wrote: > Only two were broken and they were trivial fixes. Maybe this means we are > behind on our test writing!!! Yes, yes we are.... > I was hoping you'd volunteer! I'm a terribly messy coder and I really like > having someone else's structure to work against. So please have at it.. > just let me know what your style guidelines are. > I think a simple place to start here would be Guido's python style guidelines.(http://python.sourceforge.net/peps/pep-0008.html) make sense to work in a style used in the core libraries and I normally try to follow these. > I was thinking the feed method on IncrementalParser (which just takes > string data) would obviate the need for a file-like interface. If you > look at the parse method, all it does is loop through the source parameter > calling read and passing the results to feed anyway... and even so, the > DataQueueStream has a read() method that would work just fine for parse (I > think). Ok.. cool, I'll look into this. So basically, we are going to work around the read() method and use it for all our parsing needs... off to the Incremental Parser source I go.... it was just throwing a wierd exception at me when I was doing some interpreter testing the other day. Sean |
|
From: Gabe W. <gw...@wa...> - 2002-03-01 18:53:50
|
On 1 Mar 2002, Sean Allen wrote: > On Fri, 2002-03-01 at 04:29, Gabe Wachob wrote: > > Checked in a bunch of edits to the core stuff tonight (er, its 4:20am - > > thats morning I guess). > > Up late eh? ;-) I "went to bed" at 6 and got up at 8:30.. A huge latte later and I'm back at work! > Wow.. all the tests run OK.... Only two were broken and they were trivial fixes. Maybe this means we are behind on our test writing!!! > > I'm thinking we need to do a major code cleanup (stylewise, naming, > > commenting, etc) and I'd like someone who has more energy for that to be > > the lead, if someone would be so kind. > > I'd be keen, I like that kind of stuff anyway. I was hoping you'd volunteer! I'm a terribly messy coder and I really like having someone else's structure to work against. So please have at it.. just let me know what your style guidelines are. > > Hopefully I didn't step on anybody's plate of work here.... > > Glad to see you're feeling better Only marginally now that I'm working on 2 hours of sleep ;-) > One thing I have run into in terms of using the incremental parser, is > that the object you need to hand to it definitely needs to have a file > interface (I have yet to dig deeper into this 'cos of time) so that is > something to consider, if anyone is working on streams at the moment. We > need to finalize what we are going to hand to the parser. (i.e. > stream.getData(), or just give it the stream, or > stream.getData().getByteStream() or whatever) I was thinking the feed method on IncrementalParser (which just takes string data) would obviate the need for a file-like interface. If you look at the parse method, all it does is loop through the source parameter calling read and passing the results to feed anyway... and even so, the DataQueueStream has a read() method that would work just fine for parse (I think). -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-03-01 18:40:28
|
On Fri, 2002-03-01 at 04:29, Gabe Wachob wrote: > Checked in a bunch of edits to the core stuff tonight (er, its 4:20am - > thats morning I guess). Up late eh? ;-) > Basically, I wrote the scheduler, and added in the hooks to the channel > code. Added some new listener/event types and added some methods to the > channel. The main thing left with that is to refactor sendToPeer to queue > up messages in the outgoingMQueue instead of trying to directly write > frames to the session. The scheduler will be called to "grab" frames from > channels which are ready to write, instead of simply being dumped frames > from channels as the channels feel the desire. This all looks pretty cool. I have been sketching out a few ideas for the session end of it in my head, I guess now it'll be a lot easier. > I also fixed some little bugs that were breaking test cases. I didn't > write any test cases for the new code commited (bad me), but that is > definitely on my list. Wow.. all the tests run OK.... > I'm happily surprised to see that most of the complicated code in the cor= e > of channel is for getting data in from the wire and sending it to > profiles, which is something I'm leaving untouched - its just the path of > data from the profiles through channels to the session and the wire which > is getting a makeover. Its turning out to be pretty straightforward and > maybe something the java beepcore people might consider. >=20 > I was also thinking about threading - I think there are essentially two > threads in the core plus whatever threads one desires in the app space. > The two threads are a reader (ie from the wire to the channels/profiles) > and a writer (which the the scheduler who takes data from the > profiles/channels and puts them on the wire to the remote peer). >=20 > I didn't get any reaction to my last posting about the architectural > diagrams I posted http://pybeep.sourceforge.net/arch.png, so I'm assuming > its understandable and there aren't any issues. Its now largely > implemented, or at least sketched out in code. Yes, it was all pretty clear > I know that I had divied up this task list to Sean and Huston, but I hav= e > not heard from you guys in a little while and I thought it would be easie= r > to pound this stuff out in code rather than try to go too much farther > describing it. Ahh, well, I've had to put a lot of time into the ol' job hunt, but thankfully I have this weekend to myself again, so... > Anyway, as always, the source is your best bet at this point. >=20 > I'm thinking we need to do a major code cleanup (stylewise, naming, > commenting, etc) and I'd like someone who has more energy for that to be > the lead, if someone would be so kind. I'd be keen, I like that kind of stuff anyway. > Hopefully I didn't step on anybody's plate of work here.... Glad to see you're feeling better One thing I have run into in terms of using the incremental parser, is that the object you need to hand to it definitely needs to have a file interface (I have yet to dig deeper into this 'cos of time) so that is something to consider, if anyone is working on streams at the moment. We need to finalize what we are going to hand to the parser. (i.e. stream.getData(), or just give it the stream, or stream.getData().getByteStream() or whatever) Sean |
|
From: Gabe W. <gw...@wa...> - 2002-03-01 12:29:23
|
Checked in a bunch of edits to the core stuff tonight (er, its 4:20am - thats morning I guess). Basically, I wrote the scheduler, and added in the hooks to the channel code. Added some new listener/event types and added some methods to the channel. The main thing left with that is to refactor sendToPeer to queue up messages in the outgoingMQueue instead of trying to directly write frames to the session. The scheduler will be called to "grab" frames from channels which are ready to write, instead of simply being dumped frames from channels as the channels feel the desire. I also fixed some little bugs that were breaking test cases. I didn't write any test cases for the new code commited (bad me), but that is definitely on my list. I'm happily surprised to see that most of the complicated code in the core of channel is for getting data in from the wire and sending it to profiles, which is something I'm leaving untouched - its just the path of data from the profiles through channels to the session and the wire which is getting a makeover. Its turning out to be pretty straightforward and maybe something the java beepcore people might consider. I was also thinking about threading - I think there are essentially two threads in the core plus whatever threads one desires in the app space. The two threads are a reader (ie from the wire to the channels/profiles) and a writer (which the the scheduler who takes data from the profiles/channels and puts them on the wire to the remote peer). I didn't get any reaction to my last posting about the architectural diagrams I posted http://pybeep.sourceforge.net/arch.png, so I'm assuming its understandable and there aren't any issues. Its now largely implemented, or at least sketched out in code. I know that I had divied up this task list to Sean and Huston, but I have not heard from you guys in a little while and I thought it would be easier to pound this stuff out in code rather than try to go too much farther describing it. Anyway, as always, the source is your best bet at this point. I'm thinking we need to do a major code cleanup (stylewise, naming, commenting, etc) and I'd like someone who has more energy for that to be the lead, if someone would be so kind. Hopefully I didn't step on anybody's plate of work here.... -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Gabe W. <gw...@wa...> - 2002-02-24 01:09:26
|
There is now an architecture diagram in a new dir in the codeline called doc. The arch diagram is also on the pybeep site at: http://pybeep.sourceforge.net/arch.png This should be nothing new for Sean and Huston - if there are questions, please let me know asap! -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Gabe W. <gw...@wa...> - 2002-02-21 23:51:45
|
We've had a *very* productive discussion on #beepnik today about the next priorities. In particular, we've uncovered areas that are going to diverge from the java beepcore both for language issues (certain things are better done differently in python) and for architectural reasons (I wanted to have a scheduler handle the ordering of frames written to a peer instead of a "first produced, first written" model - this would allow for pluggable strategies for perhaps prioritizing output from certain channels to a peer). This is the list we came up with of priorities (this list only makes sense if you read the chat logs!): 1) Make DataQueue an actual class so we can deal with it properly 2) Decided on an interface for DataQueueStream and whether we need a InputDQS and OutputDQS 3) Implement the mime-parsing stuff (there is code in datastream for general header-parsing a la HTTP -- is that needed?) 4) Work on the outgoing message queues and refactor sendToPeer in channel.py 5) Work on incoming message queue and any events that need to created/generated 6) Work on session and scheduler interfaces 4,5,6 can happen in parallel We identified that most of the DataStream (not DataQueueStream) stuff is cruft from the java port that we aren't going to use. Huston Franklin (frmly of Invisible Worlds, coauthor of java beepcore) has joined as a committing contributor. If you are interested in our lengthy discussion today, please see http://beepnik.wiredobjects.com/logs/2002-02-21.txt As always, chat logs and urls (from the chump bot) can be found at http://beepnik.wiredobjects.com -Gabe (your ill beepnik) -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-02-21 09:51:59
|
Hi Did some work this evening on Session. have begun to implement the abstract Java class, as we need something to plug the scheduler into and it wasn't making much sense just writing the test case, hopefully I'll finish it (tomorrow/today) and then have a better picture of how to test a session without relying too much on the rest of the core. Sean =20 |
|
From: Gabe W. <gw...@wa...> - 2002-02-18 06:22:25
|
Is it appropriate to move all the Mock classes? It seems like some of the Mock classes are very specific to certain test cases, and by putting them together separate from the test cases they are associated with, you are creating some issues about maintenance. Not a big issue, just thought I'd bring it up.... -Gabe On 14 Feb 2002, Sean Allen wrote: > Finally got my time back ;-) > > In the test/ > > moved all the Mock* classes into their own module as it was going to get > messy later. Did a little work on the Session test. > > To foster some discussion: > Although this is very early. Has anybody( i.e. people who aren't Gabe or > me.) had any thoughts as to what kind of interface they would like for > the library. I'm not trying to solicit detailed designs, but rather a > feel of what kind of utility classes might be useful once we get the > core working. Just to look at who may want to do what with this. > > Sean Allen > > > > > -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-02-15 07:35:50
|
Finally got my time back ;-) In the test/ moved all the Mock* classes into their own module as it was going to get messy later. Did a little work on the Session test. To foster some discussion: Although this is very early. Has anybody( i.e. people who aren't Gabe or me.) had any thoughts as to what kind of interface they would like for the library. I'm not trying to solicit detailed designs, but rather a feel of what kind of utility classes might be useful once we get the core working. Just to look at who may want to do what with this. Sean Allen =20 |
|
From: Gabe W. <gw...@wa...> - 2002-01-31 01:14:53
|
[Welcome to all the new pybeep-devel subscribers] Sean- Everything sounds good except that I'm wondering if using __init__ as a factory method is a good idea. If I call a constructor on a class, (ie Message()) I almost always expect to get back an instance of that class. Perhaps there should be a MessageFactory class which has a "static" (though of course, there ain't such a thing in Python) method makeMessage()? -Gabe On 30 Jan 2002, Sean Allen wrote: > On Wed, 2002-01-30 at 07:29, Gabe Wachob wrote: > > You are saying that in the java beepcore, there is a MessageMSG class. > yes. > > I agree that there shuold be the sendXXX methods in a class corresponding > > to a channel. > > > Instead of calling it a MessageMSG, how about a "RepliableMessage" or > > something like that which is a mixin (Pythonic!!!) class when a Message > > happens to be of type MSG? (line 254 of channel.py) > so, we create a message. with possible mixin (nice idea!) that contains > functionality for sending message: > so, Message actually becomes a factory that returns an object correctly > initialised > > (pseudo code) > ... > message = Message(somechan, msgno, stream, MSG_TYPE_RPY) > |___ > step in... > Message.__init__(args): > (syncronized?) > msgobj = self.__BlankMSG() > msgobj.addBaseClass(ReplyMSG()) > msgobj.init(args) > return msgobj > > ... > are we on the same page. > > might be a little long winded, but it is certainly cleaner, (and more > OO, whatever that means, probably patternly correct too!!! ;-) > > I very much like factory's as a way to build objects, it really cuts > down on possible programmer error. > > > Notice also that there are separate replyListener and messageListener > > "interfaces" (Python doesn't formally separate interfaces from classes > > which I would call a drawback, actually). Not sure why this is importnat > > -- thought I'd just mention it. > > I could be wrong, but, > Message Listener listens for MSG > ReplyListener listens for RPY, ANS, ERR, NUL > > I normally use a mixin and then override for interfaces in py, its more > a contract showing how to use object than the way it is done in Java. > but it seems to work ok. > > Sean > > So, basically, yes, lets move the sendNUL, sendANS, sendRPY methods > > elsewhere (sendERR probably goes everywhere). > > > > -Gabe > > > > On 30 Jan 2002, Sean Allen wrote: > > > > > It's been working fine for me ;-) > > > > > > About the Messages. basically, the functionality to respond to MSG's > > > that we have in Channel is now in a class called MessageMSG, which > > > represents a recieved MSG and contains logic to reply to it (sendXXX). > > > other Messages just become a Message (which doesn't really do much). I > > > was wondering if we should break the stuff in channel.Channel out into > > > another class in message.py, or unify it into a single Message class > > > that handles all of the above. > > > > > > Sean > > > > > > On Tue, 2002-01-29 at 23:42, Gabe Wachob wrote: > > > > DUH! > > > > > > > > I created the list, but apparenlty I have to then subscribe to it > > > > separately (even though it lets me *send* to the list without subscribing > > > > egad). > > > > > > > > OK, now I'm subscribed. > > > > > > > > I'm not sure I followed that last email (your reply to your post about re: > > > > Messages)... > > > > > > > > -Gabe > > > > > > > > -- > > > > Gabe Wachob gw...@wa... > > > > Personal http://www.wachob.com > > > > CTO, WiredObjects http://www.wiredobjects.com > > > > > > > > > > > > > > -- > > Gabe Wachob gw...@wa... > > Personal http://www.wachob.com > > CTO, WiredObjects http://www.wiredobjects.com > > > > -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-01-31 00:24:58
|
On Wed, 2002-01-30 at 07:29, Gabe Wachob wrote: > You are saying that in the java beepcore, there is a MessageMSG class. yes.=20 > I agree that there shuold be the sendXXX methods in a class corresponding > to a channel. > Instead of calling it a MessageMSG, how about a "RepliableMessage" or > something like that which is a mixin (Pythonic!!!) class when a Message > happens to be of type MSG? (line 254 of channel.py) so, we create a message. with possible mixin (nice idea!) that contains functionality for sending message: so, Message actually becomes a factory that returns an object correctly=20 initialised (pseudo code) ... message =3D Message(somechan, msgno, stream, MSG_TYPE_RPY) |___ step in... Message.__init__(args): (syncronized?) msgobj =3D self.__BlankMSG() msgobj.addBaseClass(ReplyMSG()) msgobj.init(args) return msgobj ... are we on the same page. might be a little long winded, but it is certainly cleaner, (and more OO, whatever that means, probably patternly correct too!!! ;-) I very much like factory's as a way to build objects, it really cuts down on possible programmer error. > Notice also that there are separate replyListener and messageListener > "interfaces" (Python doesn't formally separate interfaces from classes > which I would call a drawback, actually). Not sure why this is importnat > -- thought I'd just mention it. I could be wrong, but,=20 Message Listener listens for MSG ReplyListener listens for RPY, ANS, ERR, NUL I normally use a mixin and then override for interfaces in py, its more a contract showing how to use object than the way it is done in Java. but it seems to work ok. Sean > So, basically, yes, lets move the sendNUL, sendANS, sendRPY methods > elsewhere (sendERR probably goes everywhere). >=20 > -Gabe >=20 > On 30 Jan 2002, Sean Allen wrote: >=20 > > It's been working fine for me ;-) > > > > About the Messages. basically, the functionality to respond to MSG's > > that we have in Channel is now in a class called MessageMSG, which > > represents a recieved MSG and contains logic to reply to it (sendXXX). > > other Messages just become a Message (which doesn't really do much). I > > was wondering if we should break the stuff in channel.Channel out into > > another class in message.py, or unify it into a single Message class > > that handles all of the above. > > > > Sean > > > > On Tue, 2002-01-29 at 23:42, Gabe Wachob wrote: > > > DUH! > > > > > > I created the list, but apparenlty I have to then subscribe to it > > > separately (even though it lets me *send* to the list without subscri= bing > > > egad). > > > > > > OK, now I'm subscribed. > > > > > > I'm not sure I followed that last email (your reply to your post abou= t re: > > > Messages)... > > > > > > -Gabe > > > > > > -- > > > Gabe Wachob gw...@wa... > > > Personal http://www.wachob.com > > > CTO, WiredObjects http://www.wiredobjects.com > > > > > > > >=20 > --=20 > Gabe Wachob gw...@wa... > Personal http://www.wachob.com > CTO, WiredObjects http://www.wiredobjects.com >=20 |
|
From: Gabe W. <gw...@wa...> - 2002-01-30 07:40:49
|
From Sean: "> I'm thinking that the best way to replace all the datastream complexity > stuff is to simply use (for reading) an iterator interface which would > produce a series of BufferSegment objects (frame.BufferSegment). It > wouldn't be, strictly speaking, an iterator, because it would sometimes > return nothing when the "stream" wasn't closed but nothing was available > (ie non-blocking read). But otherwise an iterator. Could we perhaps build something with an exception in this case, which could be handled further up the object model? " I would say that an exception is not appropriate because the situation would occur when there is no more buffer segments available because data is still arriving (or is expected to arrive given the message size). Maybe a "blocking" iterator (getNext()) would be appropriate, but I would think that there are sometimes when you may not want to block... -Gabe -- Gabe Wachob gw...@wa... Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com |
|
From: Sean A. <ze...@wo...> - 2002-01-28 19:41:13
|
On Mon, 2002-01-28 at 10:04, Sean Allen wrote: > Gabe Actually it's so the library can differetiate between MSG's and others (RPY, NUL etc) it all used to be inside channel but was broken out into these classes. ATM, all this is inside channel.py, maybe we should also consider breaking it out into Message class, and if that seems clunky, make a MessageMSG class following the java object model. Sean > I've just noticed that the message impl class, Message is extended to > the concrete class MessageMSG in the beepcore-j. I guess this is to > allow people to subclass message with their own implementations, do you > think we should follow this or just implement it straight in Message, > for brevity? > Sean >=20 >=20 |
