Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: [RFC][Patch] Reduce bandwith by using deltas
Home

[Freeciv-Dev] Re: [RFC][Patch] Reduce bandwith by using deltas

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <per@xxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC][Patch] Reduce bandwith by using deltas
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Wed, 6 Nov 2002 15:22:23 +0100

On Wed, Nov 06, 2002 at 12:57:22PM +0000, Per I. Mathisen wrote:
> I have no problem with using perl or python to generate code in the
> autoconf step as long as the program takes well-formed input and delivers
> well-formed output.

No. No. No. How often do I have to repeat myself? The code isn't
generated at the autoconf step. It is generated if the developer
add/remove packets or fields in packets.

> But that isn't what is happening here.
> 
> The python-written generator takes the old, kludgy network code which is
> full of special cases as input and gives as output code that is at least
> as bad. This also means that the generator itself contains these special
> cases, and that changes to the network code will necessitate changes to
> the generator. I don't like that at all.
> 
> I investigated the network code yesterday while loooking at how the
> current network code could be autogenerated using cpp alone, and found to
> my dismay that the packet definitions themselves were bloated beyond
> sanity. Big packet structs are being reused when smaller structs would
> suffice, meaning that _many_ packets send variables that are never filled
> with data.
> 
> However, in order to clean this up (and to use cpp in place of perl and
> python), we also need to impose a uniform structure on the network code. I
> think this is a good thing, since it forces us to clean up some of the
> uglier hacks and use a good API. But it also means some wider changes to
> the other code, as we will need one C struct for each packet.
> 
> I think we should do such a cleanup even if we want to use a python or
> perl generator to generate the network code, since only that way can we
> avoid having to put all kinds of ugly special cases into the perl/python
> generator itself (which to my mind will be a maintenance nightmare).

While I agree in general I think that you have to be a bit more
specific. We all agree that send_packet_goto_route is bad. Are you
talking about removing dead fields like packet_unit_info:upkeep_gold? 
Are you talking about removing nested struct like
packet_ruleset_control.rtech? Or are you talking about splitting
packet_city_request into one for rename, one for worklist and one for
each other use? What are you talking about?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  This customer comes into the computer store. "I'm looking for a mystery
  Adventure Game with lots of graphics. You know, something realy
  challenging". "Well," replied the clerk, "have you tried Windows 98 ?"


[Prev in Thread] Current Thread [Next in Thread]