Hi Jeff, Thank you for the insight, no wonder I couldn't find any Rust code!
I also feel starting with the second option is better since it has a mucher lower entry barrier so I can start hacking ASAP. I see that GNS lookup, peer info listing and identity ego lookups are implemented. Do you think adding async IO to those functionalities by mid-term evaluation is feasible? What would you like to see by the end of the GSoC? Perhaps finish the "Next on the list" items? I've used asyc IO in a few projects before. For instance I've goroutines/channels (from golang) to implement a few distributed algorithms such as for Byzantine agreement, leader election and mutual exclusion. I also used some of the Haskell async libraries namely Control.Concurrent for a project where we had to implement the log-structured merge-tree. Finally, I've used pthreads when I was working on an enterprise backup system. I don't have any async IO experience in Rust but the paradigms shouldn't be to different. Regarding those libraries, I can't say I'm familair with the state machine based ones like rotor. On the other hand, I'm familair with the concept behind Futures and Promises which is what gj and eventual_io uses. Is there a preferred async IO model for GNUnet-rs or it's still up for discussion? Kind regards, Kelong On Sat, 2016-03-19 at 19:15 +0100, Jeff Burdges wrote: > There is a project by Andrew Cann <[email protected]> on github here > : > https://github.com/canndrew/gnunet-rs > > It's referred to as "GNUnet bindings", but it's really a > reimplementation of GNUnet utils, so that Rust code can speak some > existing GNUnet IPCs. Just fyi, one cannot make literal "bindings" > because GNUnet code is too unsafe, well it's not even thread safe. > > There are a couple things one might work on here : > 1. Implement more existing GNUnet IPCs in gnunet-rs. > 2. Switch gnunet-rs to asynchronous IO using mio either directly or > indirectly : https://github.com/canndrew/gnunet-rs/issues/1 > > I'd kinda recommend doing 2 first and then doing 1 if there is time, > but > if you're more interested in learning about GNUnet itself, then maybe > just 1 from the beginning. > > Have you used asynchronous IO before? What sort of model? > After hacking around inside the GNUnet utils scheduler, I developed a > slight prejudice against basic callbacks, as used in GNUnet. And > towards something with more structure, like maybe the ADT state > machines > of rotor : https://github.com/tailhook/rotor > Do any of rotor, gj, eventual_io, etc. sound/look like something > you've > used before? I'll have a conversation with Christian this week about > what GNUnet protocols look like to try to get a sense if one of these > approaches is more amenable. > > Jeff > > p.s. There are cryptographic bindings in GNUnet utils, but that > appears > unnecessary. I'd envision individual projects that using gnunet-rs > using an orthogonal rust crypto library, either sodiumoxide, > rust-crypto, or ring, well the crypto would always be a project > talking > to itself after all. > > > > > On Sat, 2016-03-19 at 15:43 +0100, kc wrote: > > > > Dear GNUnet developers, > > > > I'm a MSc student currently studying in TU Delft, specialising in > > cryptography and security. GNUnet aligns closely with my interests > > so > > I'm very excited about this opportunity with GSoC. > > > > I'm interested and would like to know about the "Rust > > implementation of > > GNUnet utils" project. The description implied that there are > > existing > > Rust implementations, but I couldn't find any *.rs files in your > > SVN > > repo. > > > > Suppose there does not exist any Rust code yet, which utils would > > have > > the highest priority, i.e. that would benefit the most from asyc > > IO? > > > > Kind regards, > > Kelong > > > > _______________________________________________ > > GNUnet-developers mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
