poke-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Separate cmd, mi and actions in the app sources


From: Jose E. Marchesi
Subject: Re: [RFC] Separate cmd, mi and actions in the app sources
Date: Mon, 11 May 2020 10:48:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

    
       pk-cmd-ios.c  --+
                       |
                       +-->  pk-ios.c
                       |
       pk-mi-ios.c ----+
    
    Where:
    
    - pk-mi.c contains the code that dispatches IOS-related requests to the
      "semantic" routines in pk-ios.c.  For example, it would translate a
      REQUEST_OPEN_IOS to the corresponding pk_ios_open implemented in
      pk-ios.c
    
    - pk-cmd-ios.c contains the cmd machinery for the IOS-related
      dot-commands.  Basically what pk-ios.c contains nowadays, minus the
      "semantic" routines.
    
    - pk-ios.c contains the "semantic" routines to manipulate IOS.  These
      services are used

An example:consider opening an IO space.
This can be commanded in two ways:

- The user writes a dot-command in the REPL:
  (poke) .file foo

- A client sends a REQ_IOS_OPEN request message thru the
  machine-interface.

The dot-command is handled by code in pk-cmd-ios.c:

int
pk_cmd_file (argc, argv, uflags)
{
  ...
  if (!pk_open_ios (...))
    pk_printf ("cannot open file ...");
  ...
}

The MI message is handled by code in pk-mi-ios.c:

int
pk_mi_ios_open (msg)
{
  ...
  if (!pk_open_ios (...))
  {
    put_in_response_msg ("cannot open file ...");
  }
  ...
  send_response;
}

And what I called the "semantic" routine in last email, pk_open_ios
itself, is implemented in pk-ios.c:

int
pk_open_ios (...)
{
  ...
  ... pk_ios_search ...
  ...
}

That's the idea.



reply via email to

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