[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] SOC Proposal: Networking for Pygame

I think the proposal should be 'simple to use networking'.

More below...

On 5/8/06, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote: 
Even though you could claim >USEREVENT event numbers in a way that
would be unlikely to collide with existing code, I think if you are in
a situation where you have to do that, it's a sign of a larger issue -
which is that the new module would be poorly integrated with pygame's
event queues.

I personally don't see any advantage to having network "events" come
through as pygame events, if the module can't actually be integrated
into the SDL event stuff in a seamless way. In particular, if a
function like "pygame.network.pump_events" and
"pygame.network.dicovery.pump_events" needs to exist and be called,
it's a confusing step  because it is inconsistent with other modules
(there's no pygame.mouse.pump_events, for instance)


Yeah. It should be the same api, and not have separate pump functions.
Using the pygame event queue means that all event management is done
through the same api.  So people who already understand pygame events
can use networking too.


Also, having to integrate the packet handling into your main loop
wouldn't necessarily help you have good design - for some network
models, it makes a lot more sense to encapsulate the communication
with a particular connection in it's own object, so if the packets
came through as pygame events, many games would just be implementing
their own buffering/translation of the packets from the pygame event
which are then read for individual player objects and stuff. (I also
find it interesting that SDL_net didn't bother to try to integrate
with the event queue)


SDL_net does use the event queue... well they wrote a different
implementation of it which they call fast events.  See the fastevents
module in pygame.

I say if you don't have the network stuff fully integrated into SDL's
events, it's better to make network packet recieving and lobby-type
event features have their own explicit monolithic API.

On 5/7/06, Bob Ippolito <bob@xxxxxxxxxx> wrote:
> It's not really a risk. You would simply just decide on a default
> event number, and allow it to be overridden by the developer when
> they want to.
>
> -bob
>
> On May 7, 2006, at 6:20 PM, Frode Jensen
> > Bryce Allen beat me to starting the discussion here, but it is
> > already going well. I have some questions regarding the SDL events,
> > and how a networking module would use these. Since there (afaik)
> > isn't any standard network events a implementation would have to
> > use USEREVENT or higher. Wouldn't this be a risk, both to existing
> > code and to the networking code itself? The risk being events that
> > are interpretted as being of a type, when its not, and thereby
> > causing faulty data or attribute errors. Measures can be taken to
> > protect the networking module, and since there isn't many games
> > with network support yet the potential damage isn't that big so I
> > guess it could be sacrificed, but it isn't a pretty solution.
> >