AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080923171751.0756ab01@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<maxim.kozlovsky@onstor.com>,<dl-designreview@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#mh/Mailbox/design review	0	BB375AF679D4A34E9CA8DFA650E2B04E0BAC8B1C@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 23 Sep 2008 17:22:20 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
Cc: dl-Design Review <dl-designreview@onstor.com>
Subject: Re: RMC RPC API
Message-ID: <20080923172220.1e32cd5f@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0BAC8B1C@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0BAC8B1C@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 22 Sep 2008 13:58:52 -0700 "Maxim Kozlovsky"
<maxim.kozlovsky@onstor.com> wrote:

> Hello,
> 
> Here is the design document for the rmc rpc api that was checked in
> recently.
> 
> Max
> 
>  <<rmc-rpc-design.doc>> 

Well, this is a excellent step in the right direction for our software
product, so I'm psyched to see this.



Since this is ostensibly a high level API not dependent on RMC or any
particular underlying protocol, can we change the naming to remove any
mention of RMC from the API?  It would be nice to one day in the future
be free of those three letters.  I realize that might not be
immediately too convenient since it would involve renaming
functions and files and ... sigh.



page 6, I think you meant "intermittent" rather than "intermediate"

Make the requirements a bullet/number list?  It would make it easier
to see what all will be in the result.

paragraph 4.1, the last sentence is too vague.

paragraph 4.4, third sentence: is this invisible to the application
until failure?

paragraph 4.5, this would seem to imply there is no _read method for
message available on the endpoint, which would seem to be a missing
component.  I'm guessing this functionality is available through
nfx_select()?.  Might mention that specifically somewhere.  Probably
seems obvious to you, but there will always be someone that is new to
the scene.  There is a weird sort of out-of-API set of functions that
are necessary to use this API which maybe should be in the API, like
nfx_select and rmc_init_ex [see comments below] and others.

Otherwise, every single application has to implement the same

for() { nfx_select() }

loop.  More complicated apps will want to do that, but simpler apps may
just want to utilize a _read method that already implements that.
Tests are one such example, but it is really needed for completeness.
One should be able to set blocking or non-blocking, but we can probably
skip that; make it blocking only, subject to timeout of course.  If
someone wants non-blocking, they can use select.


page 10

struct timeval open_tmo

Perhaps it's not the scope of this document, but a programmer would want
to know what the interactions for timeouts might be, like does RMC
and/or this API use any signals that might interfere with the
application, etc.

page 13

There has to be a server_close function just like there needs to be a
client_close function for completeness.  One use is in signal handlers
or post signal handler code; I assume that calling client_close will
cause deallocation callbacks to be invoked for all outstanding memory.

page 18

I feel strongly that rmc_init_ex() should be handled by the API.
Because libraries use RMC "behind the scenes", it's isn't reasonable to
have this added to every app.  It should be quite trivial to handle
this in the API somewhere in either the client or server init functions
since one of those always has to be called first, yes?  I realize that
it wont' necessarily know the "real" application name, but it isn't
actually necessary to know that anyway.  pm might need to know in the
case of daemons it controls, but otherwise a unique arbitrary string
should suffice.  The API can check to see if it needs to call it and
take care of it if it hasn't been called already.



Cheers,

a
