Re: [GNUnet-developers] towards gnunet 0.9.x

[Milan Bouchet-Valat]

Le samedi 30 mai 2009 à 12:47 -0600, Christian Grothoff a écrit : 
> The core really knows nothing about IP addresses (or transports).  Each 
> transport plugin is responsible for providing and validating addresses -- 
> nobody else even knows what the format of an address is, or what "port" is 
> being used (if at all).  So really the transport plugins are the ones that 
> will absolutely have to do this.  But it should be a tiny modification given 
> the right API.
No issue, except about the IP adress. Since it can be detected via
different means, we need some kind of centralization, i.e. a function
that will check for config files, then NAT, and finally use the new
framework for that. Should it be done in the nat library, or should it
just provide a function to be called by another lib?

> > Actually, I've checked again, and my boxes are UPnP, except that they
> > don't work with GNUnet's implementation ('make check' fails). So I think
> > I'll start the wrapper lib with UPnP, trying to get it working on my box
> > (that's what it's for, isn't it?) and then with NAT-PMP.
> 
> Sounds good.  The code does work with my UPnP NAT box, but obviously making 
> it 
> work with additional systems would be great.
Latest update: 'make check' now reports my IP address, so something must
have improved in GNUnet or in my box in this regard. So I'll consider
what's the more logical/robust/clean solution, assuming the current
implementation works.

> > Regarding non-blocking calls, I'm not used to network and threads
> > coding, but I'll see what I can do. I guess that means running each call
> > in a separate thread?
> 
> No, it means not using any threads.  It means using a "select" loop.  Read 
> the 
> src/include/gnunet_scheduler_lib.h API.  Essentially, instead of doing a 
> blocking read/write call, you ask the scheduler to call you once the socket 
> is 
> ready to do the operation, and then you do it.  Rather easy.
Good, I'll look at that.

> > I guess I'll have to ask you advice often... ;-)
> 
> That's fine, I'll try to hang out on IRC ;-).
Don't spend your nights on IRC for me, I think I'm going to work on this
sparsely (between exams and holidays!). I'm simply planning to follow
your schedule for 0.9.0... ;-)


Additionally, here are a few things I think could be good to keep in
mind when designing 0.9:

- We need a way for the daemon to send warning messages to the clients,
e.g. show a conspicuous message in gnunet-gtk about TCP transport
failing, library not found, etc. Logging is not usable for all cases and
is very misleading for new users that don't understand what fails. Maybe
GNUNET_ERROR already allows for this, though.

- It would be nice to allow downloads to go on on background, while
closing all clients. I think this should be performed in the daemon
itself - starting a new per-user process for that would not allow you to
close your session and come back, for example. While this feature is not
required to be present soon, keeping in the design the ability to add it
at some point would be nice

- And posting a news on the website to sum up what you said in your mail
would help people to keep in touch with the development. We've heard
many times that the sites looked like it was dead - giving details and
showing there's work going on will encourage users to persevere...

Cheers