We first need to get your application in to Google by whatever deadlines they have.
I'm seemingly listed as a mentor now and can see GNU applications when I access their site at : https://summerofcode.withgoogle.com/dashboard/ If you go there, or to this google-melange.com site, can you see a way to enter the application? If you need to identify me to them, my account there is [email protected] I donno if we need to provide you with something first though. On Mon, 2016-03-21 at 15:03 +0100, kc wrote: > 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 think one reasonable goal might be : Use mio via rotor/eventual_io/gj to provide the asynchronous IO functionality of GNUNet utils scheduler and adapt the peer info protocol from gnunet-rs to use it. We can substitute peer info with whatever Christian thinks is the most fundamental layer, but that's the one I'd expect. > 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. Ok great. > 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? I've little opinion myself. I'd just like it to be easier to read than the current GNUnet utils stuff. I think that'll be the case with any of gj, eventual_io, or rotor. I think the question is really : What model do you like? And do you have any opinions about what fits best with what situations? I'll look closer at the options and ask Christian for his opinion though too. Jeff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
