rohc team mailing list archive

[Raman Gupta <ramangupta16@xxxxxxxxx>]

Hi Didier,

> That's one point, however the counterpart is that you have to twice
more work to add the feature to the 2 programs...
Yes, maintaining the two apps can be challenging. So you can merge the two
into a single app.

>Indeed, the programs provided with the ROHC library are small, simple
>programs that help testing it. A larger, more complex program will
>probably require dependencies on external libraries/programs at some
>time in the future. Adding external dependencies to the library for one
>of its program seems too cumbersome for the library itself.

A common question that I have seen here is the need for a complete ROHC
application which is way beyond simple testing apps. The application should
be easy to use, configure and quick-to-go(live). That kind of application
will find many takers and widespread use of ROHC library. I have listed a
few basic features of such an application, but many more will be needed to
make it production ready.

So I agree with your opinion to have ROHC application code in a separate
code base but based on this ROHC library. Do we need a separate repository
for this, or can it be a sub-component of existing ROHC library. I don't
have much idea about maintaining a separate code repository, releases,
version numbers etc.

regards,
Raman

On Thu, Feb 7, 2013 at 11:36 PM, Didier Barvaux <didier@xxxxxxxxxxx> wrote:

> Hi Raman,
>
> > The Ethernet based transport application for ROHC pkts is very
> > similar in concept and implementation to rohctunnel app, because I
> > wanted to keep error simulations, stats collection and usage same.
> > However it uses link layer Ethernet transport instead of IP/UDP. Aim
> > was to provide similar and easy alternate to someone looking for a
> > link layer transport to conserve more bandwidth by avoiding UDP/IP
> > header overhead e.g. over point to point links without gateway/router
> > in between.
>
> OK.
>
>
> > Merging the two will complicate the code and confuse usage. Keeping
> > them separate will help them evolve independently without fear of
> > breaking the other.
>
> That's one point, however the counterpart is that you have to twice more
> work to add the feature to the 2 programs...
>
>
> > Examples of evolving the apps, that I am thinking are :-
> >
> > 1) ROHC multiplexing to combine multiple ROHC pkts in single
> > transport pkt to conserve more bandwidth.
> > 2) Keep Alive msgs between Compressor and Decompressor so as to clear
> > the context or restart when other side restarts or crashes.
> > 3) Service monitoring.
>
> Hmm, your idea are very interesting, however I think the ROHC library's
> source code is not the best place for that. To my opinion, the program
> that would result from the current ROHC tunnel and your ideas is a
> project on its own.
>
> Indeed, the programs provided with the ROHC library are small, simple
> programs that help testing it. A larger, more complex program will
> probably require dependencies on external libraries/programs at some
> time in the future. Adding external dependencies to the library for one
> of its program seems too cumbersome for the library itself.
>
> What do you think about this?
>
> If you agree, we could host your code on Launchpad aside the repository
> of the ROHC library.
>
> Regards,
> Didier
>
> _______________________________________________
> Mailing list: https://launchpad.net/~rohc
> Post to     : rohc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~rohc
> More help   : https://help.launchpad.net/ListHelp
>
>