Url

Managing locations is not an easy task. Now I realize that I need the ’/.reply’ receiver to know from which “remote place” the answer comes from so that it can update the corresponding RootProxy.

what we have

Actually, the only reference to a remote location used in oscit is the IpEndpointName from oscpack. This is fine as long as:

1. you only talk one language (osc)
2. you want your users to set IP addresses or hostnames and ports by hand

In rubyk, an Url can be used to reach any kind of connected device, not only network (and osc) based targets. This means that point (1) is not satisfied. The other problem is that most users don’t have any dns setup running on their local network and thus can’t use hostnames. They will end up having to find each and every IP address and write in stone in their patch. Bad, bad, bad. Point (2): no good.

what we want

I’d like to write urls like this in a patch:

oscit://example.com:5424/foo/bar  <--- far remote, using dns
example.com:5424/foo/bar          <--- defaults to oscit protocol
foo/bar                           <--- relative url
oscit://"stage camera"/contrast   <--- find host/port by service name, nice !
"stage camera"/contrast           <--- same as above
http://"web server"/status        <--- using http, resolving with zeroconf

The rules to parse such urls become quite obvious:

1. Protocol can be omitted or must be separated from host by ://
2. If host is enclosed in quotes ("..."), it’s a service name to be resolved by zeroconf
3. If the host part is not enclosed in quotes, it’s a fully qualified domain name and it must provide port numbers, except when using well known ports (http, ftp, etc).
4. And sometimes we receive a message from an IP with a port number and we just need to reply so we use SOME.IP.ADDR.ESS:port but we should not store this value in a patch.

design

From all the ideas shown above we see that an Url class should provide the following elements:

• protocol
• hostname or service name
• ip & port (can be empty until resolved)
• path

In C++, this gives:

class Url
{
...
private:
  Location location_;
  std::string path_;
};

class Location
{
...
private:
  std::string protocol_;

  // hostname or service name
  std::string name_;

  // true if using hostname instead of service type
  bool reference_by_hostname_;

  unsigned long ip_;
  uint port_;
};

location

The ‘location’ part of the Url contains the target location (when the url is going out) or the source location (when the url is coming in).

Storing locations on every url can be a waste if we need to do so very often so it could be better to just keep a pointer to a list of “known hosts” instead. This is left as an exercise ;-).