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 18:19:09 +0100

On Wed, Nov 06, 2002 at 03:49:14PM +0000, Per I. Mathisen wrote:
> On Wed, 6 Nov 2002, Raimar Falke wrote:
> > We all agree that send_packet_goto_route is bad.
> 
> Also vectors, diplstates, effects, techlists and worklists should be
> generalised so that they can be broken down into sensible network
> primitives instead of the current kludges and special cases.

How? While they may need a generalized interface I think it is ok. The
alternative is to specify the content of a worklist in the input file
of the generator and let the generator generate the code. What does
this buys us? Also in the worklist example you can't put the thing
simply knowing the layout:

struct worklist {
  bool is_valid;
  char name[MAX_LEN_NAME];
  enum worklist_elem_flag wlefs[MAX_LEN_WORKLIST];
  int wlids[MAX_LEN_WORKLIST];
};

The length is missing. And also you don't want to put this thing if
is_valid is FALSE. So there is IMHO no easy way to generate the puts
by a generator.

> > Are you talking about removing dead fields like
> > packet_unit_info:upkeep_gold?
> 
> Yes.

Ok.

> > Are you talking about removing nested struct like
> > packet_ruleset_control.rtech?
> 
> Yes.

I already removed the two instances. Too late.

> > are you talking about splitting packet_city_request into one for rename,
> > one for worklist and one for each other use?
> 
> Yes.

I don't want packet_city_request_worklist, packet_city_request_rename
and so on. Maybe we can have some more packet_generic_* and reuse
them. But a struct packet_* for evey PACKET is a nightmare.

> I think we should take a piece at a time and clean up before we
> start adding more cruft to the network layer. Agreed?

I don't know what you mean with "adding more cruft" ;)

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The BeOS takes the best features from the major operating systems. 
  It's got the power and flexibility of Unix, the interface and ease 
  of use of the MacOS, and Minesweeper from Windows."


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