gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUne


From: Jeff Burdges
Subject: Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUnet utils" project
Date: Mon, 21 Mar 2016 17:44:42 +0100

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 address@hidden  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


Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]