[Freeciv-Dev] Re: (PR#8426) wishlist: diplomacy tech flags

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8426 >


There is a standard way to setup all these sorts of things
that is partially implemented in many areas of the code. The
idea is *really* good, but should be part of a comprehensive
system that means any new code or additions to rules just has
to add a few missing API calls of its own.

Just to flesh out a bit more what I mean by system, I have
outlined the "default policy for initilization hierarchies"
that I hope shows how different code pieces should be
written so that many parts can make use of standard APIs
rather than purely local code (of course the implementation
code behind the API is always local and callbacks are the
way the new behaviour is actually carried out when one calls
a standard API).

Even just talking about things in such terms will help to
standardize the code and the way things are done over time.

Cheers,
RossW
=====

Default Policy for Initilization Hierarchies

     This is not a specific proposal, but a description of one
possible way of thinking about and organizing the Freeciv
program and its varioius elements. If all parts follow such
a model in a loose sense, then finding and consolidating code
into standard blocks and modules is greatly enhanced. This
means that adding new elements can also make better use of
existing code that leads to RAD styles of evolution.

     To make a robust scalable system based on a client/server
paradigm, the simple functional flow model is typically blocked
and reordered along the following lines:

1)  System::start()
       Subsystem::start()
         ...
     - all class, static or global system environment/storage
       and APIs are prepared
     - this includes *no* specific instance startup, but rather
       everything needed to do that in the next step
     - hardcoded defaults are used to insure *something* is
       always defined in the ultimate fallback. Something might
       just be warning messages and error handlers in the APIs.

2)  System::init()
       Subsystem::init()
         ...
     - instance data like rulesets is read for the specific program
       as opposed to generic system APIs and elements
     - all instance and case-by-case specific elements are setup
       using the standard system APIs with callbacks
     - Again consistent defaults are provided by combinatin of
       the hardcoded, ruleset and lastly commandline elements in
       that order of priority.
       Ruleset includes *.rc and any other persistent data defaults
       as oppose to hardcoded or static initializers on the onehand
       or console/stream input on the other.
     - note that there may be nested levels of init()/subsystems here.
       As an example to setup the network client, the first level
       involves all client local storage and startup APIs, then
       all system connection APIs, then all program connection
       APIs, then lastly the client/server program runtime state.

3)  System::run()
       Subsystem::run()
         ...
     - the startup code now goes into an infinite loop proceessing
       client/server requests.
     - note that additional start and init actions can be carried
       out as runtime commands calling the appropriate init() and
       start() module methods. These methods may be coded in a
       two-tiered fashion to separate the initial setup step and
       the update or actual implementation operations. Thus code
       of the foloowing form in the standard API means that one
       nevert has to worry about pre-iniitialization issues.

         public init() {
           if (null == element)
             (private) element.init_first()
           (private) init_impl()
         }

4)  System::free()
       Subsystem::free()
         ...
     - all instance subsystems are torn down in reverse order and
       persistent information saved as appropriate

5)  System::stop()
       Subsystem::stop()
         ...
     - all APIs and system (vs program) storage environment is
       cleaned up


     Once the system follows such a general model, it is relatively
trivial to arrange or add/remove new/old elements that go to just a
specific level or have all possible persisent and commandline modes
as well.

     In addition, one can put security limits on any of these so
that the commandline modes are not available to any client, but
need some server or superuser permissions. This is just a oneline
check in the standard API as in:

   public method() {
     if( !client_allowed() && !user_isRoot() )
       return;
     (private) do_method();
   }

====


James Canete wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8426 >
> 
> I'd like the ability to trade maps, create formal alliances, trading civ
> contacts, etc. to be tech flags.
> 
> For instance, to trade maps, there would be the flag "ShareMap" which
> would be attached to "Map Making".  Or perhaps even "TradeGold"
> connected to "Currency".
> 
> I haven't even convinced myself this is a good idea yet, though. (Which
> is why I haven't started coding it :) In a team game playing to win
> would involve getting around such "limitations" by passing around
> screenshots of map and vision, and even weirder behaviour, such as
> giving a city to an ally to take over so techs and gold can be leeched.
> 
> So there should also be a list of flags in tech.ruleset where the
> ruleset maker can specify which flags are enabled without learning a
> prerequisite tech.  Though that more masks the problem by giving it over
> to the ruleset makers. :)
> 
> What do you think?
> -James Canete