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

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

>> Hmm, also a redundant specification for TFTM. The server should be taken
>> from siaddr, not the URI.
>
>The URL spec allows for it, and I started this trend. 

SF seems to have lost my posting on this. I'm not going to type it all
in again. Essentially I like the unification of the URIs but we don't
need to mimic all of the baggage. If you put an IP in the URI there are
two places to get the server IP from and it's a complication.
Practically all who post on LTSP asking about separating DHCP and TFTP
are catered for with next-server. Also next-server is scoped in ISC
DHCPD, but filenames cannot be separately scoped for server and file
portion.

So my feeling is, use triple slashes to skip the host portion, i.e. null
string for host.

My desired outcomes are:

1. Minimum code footprint.
2. Backward compatible with current TFTP.
3. Has payoff, e.g. can switch between TFTP and NFS by editing the
filename if both are compiled in.
4. Makes code more modular (of course!)
5. Minimum extra config variables.
6. Other stuff I haven't thought of.

If 1+2 are satisfied, it can be a standard feature, no need for a config
option.

>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.

I think not for now, not for DHCP triggered downloads at least. A
bootloader is not a web browser.  The three /// allows the scheme to be
expanded in that direction if it is deemed worthwhile later. Other
solutions are possible, such as a proxy; I've been tempted to write a
TFTP to HTTPS proxy.