Great, the choice is made :)
I think that the best is to create a github issue and discuss the RINA-IP
gateway details there. I've created one with initial ideas we had from some
time ago: https://github.com/IRATI/stack/issues/900. But feel free to
discuss this approach - it's not written in stone - and ask about missing
2016-04-19 16:32 GMT+02:00 Jairo Eduardo López <nacarino@xxxxxxxxx>:
Thank you very much for your email.
I have been following the IRATI/stack commits these past few weeks and am
aware of the effort you and your team are currently making. Thank you very
much for making the time to think out a plan as to how I contribute to the
project and for responding my mail.
Both options are extremely interesting and I only wish I had time to
tackle both. Since I have to choose, I believe I would be most comfortable
attempting to tackle the RINA-IP gateway.
Knowing that the RINA-IP gateway is a integral part of the intermediate
stage between using current networks and RINA networks, I guess that your
team has, at least, a vision as to how such a process would function. How
would we go about transferring the necessary knowledge, software
architecture, limitations and requirements so that I can attempt to get
On Tue, Apr 19, 2016 at 12:47 AM, Eduard Grasa Gras <
Sorry for taking a while to get back to you again, it has been a couple
of busy weeks here. We've been discussing internally what could be some
interesting features for you, and discussed two options:
a) A RINA-IP gateway so that applications on the Internet could talk to
other applications running over RINA networks (think for example a server
app executing in a RINA-enabled data centre, being accessed by a client app
executing in a system that is not RINA-aware on the Internet).
b) An initial version of the faux sockets API, that translated calls to
the sockets functions to calls to the native RINA API (this way current
applications could run over RINA networks without being modified). It would
only be an initial version and skip some potentially complicated functions
such as poll or select.
Would you be comfortable working in any of these two features? If so,
which one would you prefer?
2016-04-05 2:21 GMT+02:00 Jairo Eduardo López <nacarino@xxxxxxxxx>:
Thanks for taking your time to respond to my email.
The answers to your questions are below.
a) Give or take 10 hours a week.
b) I work with C on smaller operating systems but have not touched the
Linux kernel source before. I work with ns-3, which is in C++, so I think I
can manage user-space stuff given some time.
I hope that given my current time limitations I can be of some help to
On Tue, Apr 5, 2016 at 12:02 AM, Eduard Grasa Gras <
Thanks for your email and for your interest in contributing to the
project. In order to understand what open issues would be the more adequate
for you to contribute, could you provide us with an indication of:
a) How much time (aprox) per day or week do you plan to spend
contributing to the project? (so that we can estimate how long it would
take to address an issue)
b) Which is your preferred development environment? Kernel (C) or
2016-03-30 3:48 GMT+02:00 Jairo Eduardo López <nacarino@xxxxxxxxx>:
I have been here before and asked how I could help you guys on your
I realize that you might need more full time developers, but I think
it would help if you had some sort of way of people helping you guys out
without having to quit their day jobs. This sort of thing might help you
gain more full time support in the long run.
Please take this into consideration. Feel free to contact me should
you find a concrete way I can help.
Jairo Eduardo López
Jairo Eduardo López