Re: [Etherboot-developers] Patch for TFTP-multicast released

[<ke...@us...>]

>The question is what is the natural way to extend DHCP to direct
>a client to boot from other protocols.  URLs seem a natural extension,
>as does extending the next-server option.

I like the unification of the URI scheme, but the problem with putting
the IP address in the URL is that now you have two places where the
server IP could be taken from, the next-server option (siaddr) and the
IP in the filename. I see this as a complication which could cause
unnecessary confusion and verbosity, for the sake of mimicking the
HTTP/FTP/etc practice. Only once in a while does someone ask in the LTSP
list about having the TFTP server separate from the DHCP server and
putting one next-server option in global scope satisfies 99% of them.

A minor point is that when you do use the next-server option, it has the
advantage of separate scoping.  That is to say, you can have
next-servers scoped independently of filename.

>So I suggest we just test for protocol:/// in all cases.  We should require
>at least the double slash.  And the tripple slash probably works, in
>most cases. 

My feeling is for now just make the ip:port empty, i.e. the triple
slash. Or ignore the host portion. Let the future decide if moving the
host into the filename is a good idea. You could try to push things
along by hacking hosted tftp clients to accept URIs with IPs, like ncftp
did with FTP. That may give you some existing practice to judge.

>Given that more people are used to urls than parsing the weird dhcp
>history it might be worth the little bit of extra code to parse an ip
>address if that is present.

My feeling is not for now, at least not for the DHCP triggered
downloads. A bootloader is not a web browser and we don't need to mimic
every aspect of the URI syntax.

My ideal outcomes for this URI enhancement are:

1. Zero size (ok, ok, as small as possible)
2. Backward compatible with existing practice (TFTP with no surprises)
3. Provides some enhanced functionality which encourages people to use
it, e.g. if both DOWNLOAD_PROTO_NFS and DOWNLOAD_PROTO_TFTP are compiled
in, then you can switch just by editing the filename.
4. Minimum number of config options. If 1 and 2 are satisfied, we could
even make it a standard inclusion.
5. Makes download code modular (but of course).
6. Other stuff I haven't thought of yet.