ClientCmPlugin

Context: I thought I had lost the clicker wiki forever, or at least, that I couldn't recover the part describing the late "code monkey" mechanics I had developed and used to "ease" development. It seems like some part of it had been saved in some wikidump folder in an obscure location of rsync-only file server of sourceforge. Maybe it isn't the latest version, but let's have a sample of what's in there anyway...

---

client.pl is a CodeMonkeyPlugin that performs rewrite of [KDS] client/server code, much like SlangSyntax used to do, but taking greater benefit of [IDL]-generated knowledge

Declaring interface we'll use

Each interface will use a *prefix* for its identification. It's important that one give different prefixes for different interfaces, especially if there are methods named the same way in the interfaces. Interface declaration can use either client or using keyword depending on whether you also want a struct kdsClient to be created.

syntax:

using "$servicename$":$interfacename$ as $prefix$;

client "$servicename$":$interfacename$ as $prefix$;

$servicename	the path from kds://services to the kdsService (e.g. timing, sys.paging, sys.binterpreter, dev.disk, etc)
$interfacename	the name of the declared interface on the service, just as in IDL files
$prefix	must be a C-compatible token that will be used to prefix every interface-related things like messages structure, etc. The prefix may vary from one source file to the other.

using and client statement superseeds the need for #include <api/___.api> and should precede any use of the interface (either through implementation or invokation). Moreover they must appear at top-level.

declaring a simple server

The server declaration will need either using or client to be first defined. Each server may implement any number of interfaces but they should all belong to the same service. Server declaration must also appear at top-level

syntax:

server "$servicename$" { (<server_command>|<implementation>)* }

<implementation> ::= implements $interfacename$ { <method>* }
<method> ::= method $methodname$ ( $serverinfotype$* $serverinfovar$, message $name$ ) { <code> }

the method command will generate the appropriate function prototype, using _$prefix$_$methodname$ as function name. You normally don't need to know that name unless you want to do funny KDS bypassing stuff. Functions parameter are available through the message structure (e.g. $name$->$parameter$)

Adding ServerCommands

Since 0.8.20, the "client" plugin is also able to handle server initializaion/termination and activity callback declarations. The syntax is

<server_command>::= <server_vars>|<server_methods>
<server_methods>::= on $eventname$ ($args$) { $code$ }
<server_vars>   ::= with (queue|thread) $varname$ = <value>;

A sample

Let's suppose we defined a 'test:hello' interface with methods void hello(char* who); and void bye(char* who);

@plugin "client.pl"
using "test":hello as greet;
client "display":basic as print;

server "test" {
   implements hello {
      method hello(void* we_dont_care, message m) {
         printStr(&DefaultConsole,"Hello %s!\n",m->who);
         return KDSE_OK;
      }
      method bye(void* we_donT_care, message m) {
         printStr(&DefaultConsole,"L8r, %s...\n",m->who);
         return KDSE_OK;
      }
    }
}

---

Date: Tue, 19 Oct 2004 08:34:12 -0700 Mime-Version: 1.0 (Produced by PhpWiki 1.3.9) Content-Type: application/x-phpwiki; pagename=ClientCmPlugin; flags=""; author=PypeClicker; version=3; lastmodified=1098200052; author_id=PypeClicker; markup=2; hits=49; charset=iso-8859-1 Content-Transfer-Encoding: binary