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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~rohc > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~rohc Post to : [email protected] Unsubscribe : https://launchpad.net/~rohc More help : https://help.launchpad.net/ListHelp
