a new api

[rejetto]

the first byte/char would identify what we are in front of
at the moment i planned

PS_DATA  = 01;  // posting datas
PS_EVENT = 02;  // event notification
PS_ACK   = 03;  // ack to client request (error code)
PC_GET   = 04;  // asking data
PC_CMD   = 05;  // exec command 
PC_EVENT = 06;  // event notification

[rejetto]

i'm directly creating documentation
that's the way i'm designing the new api

--- Types

little-endian were not specified

DATA            variable length data

INT             4 byte signed int

BOOL            BYTE    0 false
                     else true

DOUBLE          8 byte float

CHAR            1 byte character

STRING          char succession, without null termination

INTLIST         INT        # of elements
                INT        1st int
                INT        2nd int
                INT        3rd int
                ...

ISTRING         INT        length of text
                STRING     text

DATETIME        1 DOUBLE where 1.00 is one day, 1.00/24 is one hour

STATUS          BYTE    PSC_ONLINE
                        PSC_OCCUPIED
                        PSC_DND
                        PSC_NA
                        PSC_AWAY
                        PSC_F4C
                        PSC_OFFLINE
                        PSC_UNKNOWN

CONTACTINFO     INT        uin
                STATUS
                BOOL       invisible
                ISTRING    display
                ISTRING    nick
                ISTRING    first
                ISTRING    last

WHATLIST        BYTE   PLI_ROASTER
                       PLI_VISIBLELIST
                       PLI_INVISIBLELIST
                       PLI_TEMPVISIBLELIST
                       PLI_IGNORELIST
                       PLI_DB

--- an &RQ plugin communication is

 BYTE    id
 DATA    id-dependent data

id possible values
PS_DATA    posting datas
PS_EVENT   event notification
PS_ACK     ack to client request (error code)
PC_GET     asking data
PC_CMD     exec command
PC_EVENT   event notification


--- PS_DATA  data

succession of
 INT     # of following bytes
 BYTE    type
 DATA    type-dependent data

type possible values
PT_INT
PT_INTLIST
PT_STRING
PT_DATETIME
PT_CONTACTINFO

--- PS_EVENT  data

 BYTE   id
 DATA   id-dependent data

id possible values
PSE_CONNECTED
PSE_DISCONNECTED
PSE_MSG_GOT
  INT        sender uin
  ISTRING    msg
PSE_MSG_SENT
  INT        recipient uin
  ISTRING    msg
PSE_CONTACTS_GOT
  INT        sender uin
  INTLIST    contacts
PSE_CONTACTS_SENT
  INT        recipient uin
  INTLIST    contacts
PSE_LIST_ADD
  WHATLIST   list
  INTLIST    contacts
PSE_LIST_REMOVE
  WHATLIST   list
  INTLIST    contacts
PSE_NEWSTATUS
  INT        contact
  STATUS     new status
  BOOL       invisible


--- PC_GET  data

  BYTE   what
  DATA   id-dependent data


what possible values
PCG_TIME               // current time  :datatime
PCG_LIST               // get specified list  :intlist
  WHATLIST  list
PCG_CONTACTINFO        // :contactinfo
  INT  uin
PCG_NOF_UINLISTS       // number of uinlists  :int
PCG_UINLIST            // get specified uinlist, name and uins  :string,intlist
  INT  idx
PCG_AWAYTIME           // user inactivity time  :datetime
PCG_ANDRQ_PATH         // :string
PCG_USER_PATH          // :string
PCG_ANDRQ_VER          // each byte is a number version, A.B.C.D  :int
PCG_ANDRQ_VER_STR      // in string form  :string
PCG_USER               // current user  :int
PCG_USERTIME           // running time for this user  :datetime
PCG_CONNECTIONSTATE    // 0 offline, 1 connected, 2 connecting  :int

--- PS_ACK  data
  BYTE    id

id possible values
PA_OK            // generic acknowledge
PA_NOUSER        // no user running
PA_UNEXISTENT    // the one you said does not exist
PA_UNK_CMD       // submitted command is not supported
PA_FAILED_FOR    // the operation went ok but for these uins
  INTLIST   uins
PA_ERROR         // generic error


--- PC_CMD  data
  BYTE   cmd

cmd possible values
PCC_SEND_MSG
  INT      uin
  ISTRING  text
PCC_SEND_CONTACTS
  INT      uin
  INTLIST  contacts
PCC_SEND_ADDEDYOU
  INT      uin
PCC_LIST_ADD
  WHATLIST list
  INTLIST  uins
PCC_LIST_REMOVE
  WHATLIST list
  INTLIST  uins
PCC_SET_STATUS
  STATUS   status
PCC_SET_INVISIBLE
  BOOL     invisible
PCC_QUIT
PCC_CONNECT
PCC_DISCONNECT

[rejetto]

ok, i updated this doc above
i'm sure it's not so readable, it needs a big effort, but at the moment is mainly for my own use.
however, i would like to see comments, but probably i will see none :rolleyes:

maybe in a week i will get something working and then i will receive feedback

 

[airbug]

Here're what I want for the new API:

We (future plugin coders) must be able to create one DLL which will be put in PLUGINS directory (or whatever) and activated in &RQ configuration..

Plugins must have mainly entry and exit function calls, which will be called when activated/deactivated.

Plugins must have something called something like TYPE which tells the type (heh, not surprising?) of the plugin. To be more precise, some of the plugins must not be active in the same time. Take an history plugin.. Say there are two history plugins.  They must not work together, not to overlap.

Well, I have more to write, soon.



mov ah, 4ch; int 21h;

[rejetto]

at the moment i don't see any overlapping problem
i will add such a feature if it will be needed

 

[rejetto]

i decided to create a new api for plugins
it will be base on a single string, so it will easily fit both dde and dll system

still not sure what system will be used, both?