pybeep-devel — Developer List

[Pybeep-devel] Messages

[Sean A. <ze...@wo...>]

Gabe
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

Re: [Pybeep-devel] replacing datastream

[Sean A. <ze...@wo...>]

On Mon, 2002-01-28 at 08:46, Gabe Wachob wrote:
> 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?
=20
> Thoughts? Do we have to worry about writing to these 'datastreams'?

I think we do have to be able to construct output streams, which are
just, at a low level buffer segments that get stuffed into frames then
into the socket. So I don't think they need to be super complex. I have
been working on the message test case and will probably do so for this
morning as I have a free day.

Sean=20
> This should be a lot easier than doing the whole stream thing...
>=20
> 	-Gabe
>=20
> --=20
> Gabe Wachob                   gw...@wa...
> Personal                   http://www.wachob.com
> CTO, WiredObjects    http://www.wiredobjects.com
>=20
>=20
> _______________________________________________
> Pybeep-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pybeep-devel

[Pybeep-devel] replacing datastream

[Gabe W. <gw...@wa...>]

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.

Thoughts? Do we have to worry about writing to these 'datastreams'?

This should be a lot easier than doing the whole stream thing...

	-Gabe

-- 
Gabe Wachob                   gw...@wa...
Personal                   http://www.wachob.com
CTO, WiredObjects    http://www.wiredobjects.com

[Pybeep-devel] unit test code

[Gabe W. <gw...@wa...>]

I've checked in the first unit tests and already they've been a great help
in debugging frame.py (just beginning!)

I've decided test code should follow the conventions being used in the
python base distro:

* test code from all modules goes into separate modules under a separate
test directory (in our case, beep/test)

* test modules are named test_<name of stuff being tested> -- e.g.
test_frame.py

* use the framework of having one (or maybe more) test classes inside the
module with ancillary support classes (e.g. mock object classes) as
needed. Methods should be named test_<mnemonic for the test> so they can
automagically be picked up by pyunit

* see test_sample.py and test_frame.py

	-Gabe

-- 
Gabe Wachob                   gw...@wa...
Personal                   http://www.wachob.com
CTO, WiredObjects    http://www.wiredobjects.com

[Pybeep-devel] What is our target?

[Sean A. <ze...@wo...>]

A brand new fresh list:
I'll get it started

Does anybody have any firm ideas on what our target should be in regards
to what versions of Python PyBEEP should support. What I mean is, how
much backward compatibility should we build into the library. I know
Mike plans to incorporate it into ZOPE (which is a great idea) so AFAIK,
that gives us a minimum Python level of 2.1 (for the latest ZOPE
release). The reason I am asking is that 2.1 (and especially 2.2)
include some really nifty features like iterators and generators that
will allow us to follow the Java logic really closely, and possible
allow us to streamline a few things too. Specifically, I had an idea
about trying to implement the streams as generator objects
(stream.next() spits out the following octet as the generator object
takes care of listening to the channel, or something like that ;-)
so if we could come to some kind of consensus, that would be cool. Of
course, making it Python > 1.5.2 compatible may have some pluses too.

discussion?

Sean Allen