IDL, pidl and RPC...

[Tarmo Pikaro]

Hi !

I've began implementing some basic source code for
embedded environment for being able to use RPC in
there. I haven't using anything yet from your code,
there are several reasons why - 
1. your code if not designed for embedded environment.
2. pre-post conditions are not properly marked.
(assert/verify macros)


I have started from relatively simple example - file
encoding. I have implemented and tested it already.
Decode functionality I will implement the next.

Several issues which I want to tell you, pleae if you
find this intresting, can we continue this discussion
in private.

1. Memory management. In Microsoft RPC RPC message is
first composed and only then it is sent over internet.
In this encoder decoder concept we will instroduce
another concept - parallel encoding and sending. For
example if user wants to send 2Mb byte array. We will
not allocate 2 Mb for this purpose, instead we
allocate relatively small buffer (Let's take for
example 64Kb).
    
When encoding is done and it is noticed that buffer is
not large enough, pfnFlushEncodeBuffer function is
called. It's responsibility is to clear exisiting
buffer (by sending the data for example) and return
some free space to the encoder.

2. Error handling.
In windows rpc the whole system lacks of proper error
handling, I don't know how exacly errors are being
reported, but the error code is simply not enough.
In your implementation you also use NTSTATUS (aka
HRESULT) where one bit refers to fact of whether error
occured or not.

I have replaced NTSTATUS with bool8 (boolean, two
values - TRUE and FALSE)

Error handling is left out to the programmer
responsibility.
      Client --> Encoder --> Sending/Writing
        |                       ^
        +-----------------------+
    Error information is queried from classes below.
    
All functions below returns bool8 (TRUE or FALSE) of
whether encode/decode operations can proceed or not.

E.g.
bool8 Encode32(
    EncodeDecodeContext* pEncDecContext,uint32 Value);


I have also an idea of defining a separate error
reporting interface for each interface. (may be can be
also called as dispinterface/event dispatching
intefrace???)

interface IFileOperations_ErrorReporting
{
    void OpenFileError(
        [in] const char* pszFilename 
          //What we didn't open
        [in] eReason
          //Why it didn't open ?
    );
}

It seems to me that it can become quite huge problem
after a while.



Some questions to you:
1. What do you think about XML? Some of my collegues
really believe that it will save the world. Meanwhile
I have some expirience with it and now when I'm
comparing your existing rpc system and how it could be
potentially done with XML, I still think that XML does
NOT saves the world. It's too complex and too
overdynamic system. It can be used for replacing .ini
files, but not for encoding files and generating
communication rpc messages.

2. Can you suggest me some file encoding/generating /
decoding/parsing libraries/routines ?

Could the the IDL mechanism be used for generating
files? So you make an RPC call and it gets saved in
file. :)

3. Another question - how alignment is handled in IDL
with custom / complex structures?
typedef struct
{
   uint8   a;
   uint32  b;
}MyStr;

How this gets encoded into rpc message ?
a, filler byte * 3, b ?
Or is it always alignmed by 1 ?

4. size_is usage inside struct. I have tried midl - it
does not accept such syntax, but pidl accepts it fine.
Your own extension?

If someone would send me his mail / phone number I
think it will be possible to communicate more
fluently, than over this mailing system...










		
__________________________________ 
Do you Yahoo!? 
Yahoo! Personals - Better first dates. More second dates. 
http://personals.yahoo.com