AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080924120409.645b4abc@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	BB375AF679D4A34E9CA8DFA650E2B04E0BAC9158@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 24 Sep 2008 12:04:55 -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: <20080924120455.33b156be@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0BAC9158@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0BAC8B1C@onstor-exch02.onstor.net>
	<20080923172220.1e32cd5f@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0BAC9158@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 Tue, 23 Sep 2008 18:02:21 -0700 "Maxim Kozlovsky"
<maxim.kozlovsky@onstor.com> wrote:

> 
> 
> >-----Original Message-----
> >From: Andy Sharp
> >Sent: Tuesday, September 23, 2008 5:22 PM
> >To: Maxim Kozlovsky
> >Cc: dl-Design Review
> >Subject: Re: RMC RPC API
> >
> >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.
> >
> [MK] No, I like those three letters :P. If we want to change that we

Well there's no accounting for taste ~:^)

> >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.
> [MK] 
> There is already utils_send() for trivial synchronous cases like
> shells or tests. Every other application has to implement select
> loop, making this task easier is another story and out of scope here. 

I'm not talking about making the task of implementing the select loop
easier, I'm talking about implementing the trivial case in an API
function called rmc_read_ or rmc_wait_message or something, which would
get a lot of use if it existed.  Which is kind of the point of APIs.
Or one of the points, anyway.

> >
> >
> >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.
> [MK] There are no additional signals introduced, I didn't see the need
> to make this explicit. The RMC uses SIGALRM which must be mentioned
> somewhere in RMC design doc.

I realize you didn't see the need, which is why I brought it up ~:^)
Possibly it doesn't belong in this doc.  Perhaps this doc could have a
ref to the other one, which I didn't know existed.


> >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.
> 
> [MK] That will require additional parameters for each
> rmc_client_init() or rmc_server_init() that are used only once, which
> does not look right. I can make sure the init functions return
> failure if rmc_init_ex() was not called, that should take care of
> your concern.

It shouldn't require any additional parameters, which I was trying to
hint at when I said a unique arbitrary string should suffice.  If
rmc_init_ex hasn't been called, the _init method can create an
arbitrary, notice I didn't say random, unique string and use that.  If
the app itself doesn't care, then neither does anything else.


