Hi Didier, Please share your thoughts on this with me, to take it further.
regards, Raman On Mon, Feb 11, 2013 at 1:19 PM, Raman Gupta <[email protected]> wrote: > 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
