Article:
  Why I Stopped Coding and Why I'd Start Again
Subject:   Why This Needs Commercial Sponsorship
Date:   2007-01-20 11:49:25
From:   brian.mcconnell
Hi. I wanted to respond to some of the comments that have been posted or sent privately.


Clearly it is easy enough to modify a language to import from a URL (or use filesystem trickery to do this as is).


This will work well enough, except that it is inherently insecure, and more importantly, unstable. The URL might change, or the repository might disappear.


This is where a company that's in a position to set standards can do everyone a favor by hosting the code repository, and in the long run, create a DNS namespace for code. Then developers will know that the system is reasonably secure, and is likely to be around for a long time.


Also while I used Python in this example (it's my favorite language), there's no reason this cannot be implemented in other languages. I'd like to see this become standard practice.


Lastly, I did not mention this in the article, but this facility will be very useful for mobile devices, which typically have limited storage for apps. With this system, the mobile device could cache the most frequently used modules, and discard the others if space is running low (and reload them next time they're needed, if ever).

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Why This Needs Commercial Sponsorship
    2007-01-22 20:52:32  donbarthel1 [View]

    <<
    This will work well enough, except that it is inherently insecure, and more importantly, unstable. The URL might change, or the repository might disappear.
    >>

    I don't think that this has to be insecure for the reasons you state. Caching can be used here. If the system is optimized (not unlike the DNS system) to cache URL-imported modules locally, at both the client and referring server (the server that hosted the code that issues the #import URL statement), then if a URL changes, the copies at the client and referring server could be used, even if expired (expired from the cache). The copy at the referring server would be unlikely to dissappear since the original program (or referring module) is hosted by it.

    This whole thing needs a heirarchy of caching at the client and at the reffing server anyways to optimize performance. I'm just suggesting that this heirarchy could be used to solve the 'URL might change' problem.