Rewrite net::ip without using libuv

[brson]

Some networking definitions are going to need to be defined in core, at least for a while, and that includes IP addresses. std::net::ip uses libuv though and I intend not to put uv in core.

May block #4419

[yichoi]

not use libuv but directly use something in libc. e.g inet_ntop ?

[brson]

Yes, that's what I was thinking. Now that I'm looking at it though, maybe it's not necessary to put all that logic into core.
We could instead redefine IpAddr to not depend on uv's sockaddr_in and sockaddr_in6 types, create conversions between it and the uv types, put IpAddr into core, and leave at least some of the logic in uv. It sort of depends on how much functionality uv is giving us here, how difficult it is to reproduce, and how much extra code will be required in core.

Either way, the determination of what I/O code lives where is something we can revisit later, so we don't need to worry too much about making the wrong decision here. The most important thing is that the abstract I/O types in core can mention IP addresses without depending on libuv.

[graydon]

Revisited 2013-05-29, still seems legit and properly classified.

[emberian]

Visiting for triage; nothing to add

[martindemello]

is this still valid/open?

[martindemello]

Don't know enough to do it, I'm afraid; I was trying to find CLs that
addressed it and wondered if there weren't any because the bug had gone
invalid for whatever reason.

On Tue, Sep 24, 2013 at 8:49 PM, Jeff Olson notifications@github.comwrote:

@martindemello https://github.com/martindemello yeah.. the plan is
somewhat roughly-sketched-out; i think it's something like:

• do Towards a pluggable EventLoop, etc #9128 Towards a pluggable EventLoop, etc #9128
• decide whether or how and at what API boundary to draw the line
  (possibly at the RtioFoo interfaces)
• assuming the above bullet holds, re-implement all of the RtioFootraits in a new module (a sibling to
  std::rt::uv), that uses "platform-backed" implementations using
  idiomatic APIs for each platform (so mostly POSIX/etc on linux, POSIX+
  NSFoo on OSX, win32 on windows, etc...) .

There would be stuff like RtioTimer (where we have std::io::timer::Timerprobably implementing
std::select::Select in the near future, unless we want to go down the
rabbit hole and move std::select's entire impl to be behind the
IoFactory.. then maybe we could do something rational at the
per-platform/OS level) that might not translate cleanly. I'd love to
identify a subset of the RtioFoo traits (or maybe at some other level?
not sure) that we can definitely do in notional std::rt::pb module (pb
for platform-backed).

An additional caveat to the third bullet, above, is that these
implementations would be "truly blocking" and would do no
task-descheduling-magicks (as is done, currently, in uvio), so they could
be conceivably used without the rust scheduler. Not sure how to get around
in case(s) where the platform API is async (this is bound to come up, I'm
sure). Hence my hedging as outlined in bullet 1.

@brson https://github.com/brson and I have had a few conversations
about this in IRC, and I have a topic branch working towards #9128https://github.com/mozilla/rust/issues/9128in my local repo. But not much actual movement on this. If it's something
you're interested in working on, feel free to drop by #rust and we can chat

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4956#issuecomment-25060473
.

[catamorphism]

Obsolete