Arc Forumnew | comments | leaders | submitlogin
IDEA: Loading remote files
13 points by stefano 6081 days ago | 9 comments
Traditionally, files are loaded directly from the hard disk:

  (load "file.arc")
will search for the file in your local machine.

The idea is to let load take an URI instead of a path, and making it loading the file in a trasparent manner, even if it is a remote file. For example

  (load "http://arclanguage.com/lib/myfile.arc")
would fetch the file from the web and then load it in the interpreter.

What do you think about it? Could it be useful in your opinion? Do you think it would expose programs to security issues?



5 points by kens 6076 days ago | link

Making this part of "load" seems a bit special-case. I think it would be more general to make "infile" support this, and then you get "load" for free.

Obviously there are plenty of security issues. "load" from the file system has security issues to start with, but when you're loading over the network, you have little guarantee that what you're loading is what you think you're loading. (DNS poisoning, packet insertion, etc.) Using https instead of http would help.

If you go down the distributed computing path, just make sure you don't reinvent Jini :-)

-----

4 points by KirinDave 6080 days ago | link

People do this in Ruby, and it can be fairly useful when building distributed systems. Another approach is to make something like

  (load 'foobar)
Check all the local codepaths for foobar, and if those fail then check the remote codepaths. An example of this approach was used in my projects, here's a link to the code that did it in ruby: http://github.com/KirinDave/fuzed/tree/376747981d7801d3e8ba2...

-----

5 points by rosejn 6077 days ago | link

I think it's a great idea with many uses. The obvious concern is with security, and loading remote code you haven't really checked out yet. In Ruby there is a sandbox library that lets you do this kind of thing while limiting the damage a random library can do to your system. Has there already been discussion of a sandbox mechanism for Arc? As the line between client and server is blurring it might make sense to include sandboxing as a basic feature early on...

-----

3 points by stefano 6077 days ago | link

I think that some kind of signature (provided by a trusted source) should suffice. Sandboxing is propbably the most secure thing to do, but it has a few drawbacks:

1) It could potentially limit the functionalities if the loaded code (e.g. access to the filesystem)

2) Efficency, because almost every operation (such as memory accesses) should be checked to be sure the application doesn't try to get out of its sandbox.

3) Implementation: it doesn't seem to be very easy to implement :)

-----

5 points by bd 6079 days ago | link

I must confess I used (tostring (system "wget -O - http://...")) when working through an example in Software Engineering for Internet Applications (http://philip.greenspun.com/seia/). This let me capture the HTML into a string for processing.

-----

2 points by projectileboy 6079 days ago | link

I think this is an awesome idea, but you should also read this before you dive into an implementation: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...

-----

1 point by tokipin 6081 days ago | link

funny, i was thinking about something like this today. manually downloading/installing libraries is annoying for the programmer, and when they want to release their program they have to either package the libraries or tell people they have to download additional things

instead, it would be nice if the libraries were automatically downloaded the first time they are encountered, so that the programmer could just distribute their file(s)

linux does packaging thingies now... though i haven't used linux in a few years so i dunno how it works. we can allow the programmer to not only specify a library, but also a hash to make sure it's the precise desired file

-----

1 point by absz 6081 days ago | link

That sounds like a really good idea. It might be nice to have some sort of caching mechanism, but it's nice when you want to try something (e.g. the n-back game posted recently).

-----

1 point by cpfr 6076 days ago | link

Network transparent code is a good thing. A related tool that this can work off is live code loading and communication.

-----