Hi,
At Denver Meeting I have suggested three policies for API mapping
for PPDT specification.
- Type A,
The PPDT provides only primitive API set. These atomic functions
have limited capabilities. If a client process of a PPDT context requires
more complex functionality than these atomic APIs can do, then each
vender shall provide over layered protocol driver to facilitate other
APIs.
- Type B
The PPDT has well experienced common API set like SBD Sockets.
And any client process over PPDT shall call these common functions.
- Type C
The specification of PPDT describes nothing about API.
To shorten schedule to fix specification of PPDT, “Type C” could be
the "best buy".
Any PC OS vender may provide their common API set to support PPCT
according to their own policy.
I believe the interoperability testing between device A and device B does
not require API definition over PPDT. Each device does not care for PPDT
implementation hidden in the counter peer.
Only the test version of a PC driver which is required being directly used
from various test applications shall provide known APIs. An example of
atomic APIs for this purpose are listed below:
But I was silly for this point also, because any PC OS vender has freedom
to define their proprietary API set even when they makes a test software.
------------
int32 LookupService(Service_Name *list_of_service);
int32 RegisterService(Service_Name new_name);
int32 OpenPPDT(int64 guid, int64 reserved, struct ppdtaddr* );
void ShutDownPPDT(int64 guid, int64 reserved, struct ppdtaddr* );
Service_Handle OpenConnection(char *name_of_service);
int32 CloseConnection(Service_Handlde service);
int32 ReadAsync(Service_Handlde service, char *buff, int32 *size);
non blocking mode
int32 WriteAsync(Service_Handle service, char *buff, int32 size);
non blocking mode
int32 ReadSync(Service_Handlde service, char *buff, int32 *size);
blocking mode
int32 WriteSync(Service_Handle service, char *buff, int32 size);
blocking mode
int32 FlushQueue(Service_Handle service);
bloking mode only
------------
I prefer “Type C” rather than Type A or B and I’d also like to suggest
eliminating the interoperability testing because it would be just a
“show”.
For PC peripherals, APIs for PPDT are hidden in each PC operating system,
and an abstraction layer of each operating system normally provides
common API set to client apps those know nothing about characteristics of
PPDT.
So now, let us clse tow issue { 1. API mapping and 2. The interoperability
testing } ?
Both these are meaningless for us.
How do you think about these points?
-------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to nagasaka.fumio at exc.epson.co.jp