[RTPproxy Devel] About data structure naming(pls reply to my email box directly)

[Zhang William]

Dear Maxim,

Thanks for your detailed answer about this question! And I fully understand
your concern.
>From the view of RTPproxy users, the naming is not important indeed. It's
just like a black box.
I have to say, at the time being, I don't have time to apply this change
either.  When I have time to work on this, I will let you know.

OK, get the lastest cvs trunk before sumitting a patching is always correct.


Best regards,


William




On 7/21/08, Maxim Sobolev <sobomax at sippysoft.com> wrote:
>
> Dear Zhang,
>
> The suggestion has certain merits, however I would like to point out that
> there should be a balance between name clarity and convenience, as long
> names are harder to type and the chance of making a typo is higher. That
> being said, indeed there are several structure members in the RTPproxy whose
> names could be improved. However, I don't have a time to do re-name by
> myself, so that if you feel like it you are welcome to do it by yourself and
> submit a patch. I will get it committed if it makes sense.
>
> As for the inbound/outbound separation, in many places the ability to use
> index to address specific side of the session makes code much more compact,
> so that I am not convinced that using separate structures is justified.
> However, if you show me the patch that implements it without obscuring the
> code or bloating it significantly I would certainly consider it.
>
> If you submit a patch, please make sure you are using the latest version
> from the cvs trunk, as we've done significant code re-organization recently.
>
>
> Zhang William wrote:
>
>> Hello Maxim,
>>
>> I am thinking whether we can apply some changes to the source code. I feel
>> some parts of the codes is not so easy to understand.
>>
>> As a sample, I list one structure here:
>>
>> struct rtpp_session {
>>  /* ttl for caller [0] and callee [1] */
>>  int ttl[2];
>>  rtpp_ttl_mode ttl_mode;
>>  unsigned long pcount[4];
>>  char *call_id;
>>  char *tag;
>>  rtpp_log_t log;
>>  struct rtpp_session* rtcp;
>>  struct rtpp_session* rtp;
>>  /* Remote source addresses, one for caller and one for callee */
>>  struct sockaddr *addr[2];
>>  /* Flag which tells if we are allowed to update address with RTP src IP
>> */
>>  int canupdate[2];
>>  /* Local listen addresses/ports */
>>  struct sockaddr *laddr[2];
>>  int ports[2];
>>  /* Descriptors */
>>  int fds[2];
>>  /* Session is complete, that is we received both request and reply */
>>  int complete;
>>  int asymmetric[2];
>>  /* Flags: strong create/delete; weak ones */
>>  int strong;
>>  int weak[2];
>>  /* Pointers to rtpp_record's opaque data type */
>>  void *rrcs[2];
>>  struct rtp_server *rtps[2];
>>  /* References to fd-to-session table */
>>  int sidx[2];
>>  /* Reference to active RTP generators table */
>>  int sridx;
>>  /* Flag that indicates whether or not address supplied by client can't be
>> trusted */
>>  int untrusted_addr[2];
>>  struct rtp_resizer resizers[2];
>>  struct rtpp_session *prev;
>>  struct rtpp_session *next;
>>  struct rtpp_timeout_handler *timeout_handler;
>> };
>>
>
> Sincerely,
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> T/F: +1-646-651-1110
> Web: http://www.sippysoft.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rtpproxy.org/pipermail/devel/attachments/20080726/fde4f4af/attachment.html