@notjack axon/net2 updated with host supertype and string<->foo API

the code keeps getting cleaner and tighter

No fuss on the axon side

racket@data.rkt> (string->authority "localhost:345") (authority (dns "localhost") 345) racket@data.rkt> (string->authority "192.168.1.234:345") (authority (ip4 #"\300\250\1\352") 345) racket@data.rkt> (string->authority "[::1]:345") (authority (ip6 #"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1") 345) racket@data.rkt> (string->authority "[::]:345") (authority (ip6 #"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0") 345) racket@data.rkt> (string->authority "[::]") (authority (ip6 #"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0") #f) racket@data.rkt> (string->authority "::") uncaught exception: 'AUTHORITY-SYNTAX

The dns host type remains a stub (boxed string)

On the axon side, I’m using string->authority, host->string, authority-host and `authority-port.

I get the feeling it could be using URIs, instead. Is there a scheme type for basic TCP connections? Is a TCP connection endpoint considered an identifiable resource?

<tcp://localhost:3600>

tcp://[::]:3600

Well, IANA scheme registry has no entry for tcp. Google returns some vendor-specific stuff, not so useful.

@dedbox re: axon cleanliness - fantastic, that means the choice of data structures for net2 is headed in the right direction re: scheme types for TCP - there isn’t a scheme for it because there is no notion of “resources” in TCP, there are only bytes sent and received with no inherent meaning given to them by TCP itself

so there’s no way to determine what to do differently for URLs like <tcp://example.com/foo>, <tcp://example.com/bar>, and <tcp://example.com/baz?blah#whizbang>

according to the spec those should all be different resources, but how do you send the resource path over TCP? TCP doesn’t define any way to do that because it doesn’t operate at the level of resources at all

Ok. URIs are so much more deliberately designed than I realized.

I had the same experience when I started digging into this stuff too :) it’s amazing how much consideration and useful design work went into them

@dedbox status: I’m working on some concurrency utilities (including the ones mentioned in #general the other day) in hopes of adapting the disposable interface to use synchronizable events. This has the upshot of making sure I understand concurrent ML well enough to pick the right APIs for connectors and listeners. The utilities include a bunch of documentation that should (hopefully) help you, me, and future net2 users / contributors understand how the async IO part of it works.