D - import http...
- Russ Lewis (10/10) Jun 12 2002 How about allowing imports of remote files through HTTP/FTP? It would
- Matthew Wilson (5/15) Jun 12 2002 That appeals.
- Robert W. Cunningham (31/36) Jun 12 2002 Under Linux, it is easy to mount an FTP site as a (very slow) file syste...
- Matthew Wilson (6/43) Jun 12 2002 The FTP and CVS integration is easily achieved into the shell as
- Russ Lewis (12/12) Jun 13 2002 Lots of good points about Linux filesystems. I, too, am a big fan!
- Martin M. Pedersen (11/12) Jun 13 2002 Hi,
- Matthew Wilson (7/19) Jun 13 2002 Thanks Martin.
- Russ Lewis (9/21) Jun 14 2002 It's a very valid point. Yet I've got this gut feeling that if we inclu...
- Robert W. Cunningham (14/26) Jun 14 2002 When using CVS as a filesystem, you can configure it to do checkouts
How about allowing imports of remote files through HTTP/FTP? It would
be good in the import statement:
import "http://www.cooperativedevelopment.com/foo.bar.d";
but would also be a good thing to be able to define in the include path.
Maybe this is for version 2.0...
--
The Villagers are Online! villagersonline.com
.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jun 12 2002
"Matthew Wilson" <dm synesis-group.com>
That appeals.
I'm sure there must be negatives (aside from the implementation effort)
however. [Too early in the morning to think of any though ...]
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D0783D0.6D15127F deming-os.org...
How about allowing imports of remote files through HTTP/FTP? It would
be good in the import statement:
import "http://www.cooperativedevelopment.com/foo.bar.d";
but would also be a good thing to be able to define in the include path.
Maybe this is for version 2.0...
--
The Villagers are Online! villagersonline.com
.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jun 12 2002
Russ Lewis wrote:
How about allowing imports of remote files through HTTP/FTP? It would
be good in the import statement:
import "http://www.cooperativedevelopment.com/foo.bar.d";
but would also be a good thing to be able to define in the include path.
Maybe this is for version 2.0...
Under Linux, it is easy to mount an FTP site as a (very slow) file system.
I don't know if similar things exist for Windows, but I wouldn't be
surprised if they did.
Even better would be to mount a remote CVS archive as a local file system,
another thing you can do in Linux. That one I doubt is possible under
Windows.
Under Linux you can also place an "overlay" file system between the local
system and the remote site, so your writes "look and feel" as if they go to
the remote site, but are actually maintained locally (because the mount is
local). This is especially useful when the remote filesystem is
read-only. For example, overlay file systems are often used by the
bootable CD Linux systems, so you can have your entire file system on the
CD, and you only need a small amount of file space on the local disk for
the overlaid write image. When you restart, the overlay can be
automatically restored.
See why I hate Windows? It's just too hard to have any real fun there.
Unless you like Solitaire, of course.
What may be more useful to the D build environment is a way to hook in
external customized tools. For example, if all accesses to user files
could be passed out to a helper app, then that app can use some smarts to
decide where to go to get the file: The local disk, the Web, or an FTP
site. The easiest way to do that is to virtualize the entire file access
layer. If POSIX calls are used (instead of native Windows calls), then I
can link the D tools with my own POSIX library that has my own snake oil
built into it. The calls I don't modify just get passed through to the
underlying "real" POSIX library.
Windows has a decent POSIX layer, so it should make no difference to local
(default) functionality. But it would sure help in adding extra
functionality and also in porting the D tools to other environments.
-BobC
Jun 12 2002
The FTP and CVS integration is easily achieved into the shell as shell-extensions. Not sure how easy it would be to plug into the file-system itself ... "Robert W. Cunningham" <rcunning acm.org> wrote in message news:3D07DBEA.B1090CB acm.org...Russ Lewis wrote:toHow about allowing imports of remote files through HTTP/FTP? It would be good in the import statement: import "http://www.cooperativedevelopment.com/foo.bar.d"; but would also be a good thing to be able to define in the include path. Maybe this is for version 2.0...Under Linux, it is easy to mount an FTP site as a (very slow) file system. I don't know if similar things exist for Windows, but I wouldn't be surprised if they did. Even better would be to mount a remote CVS archive as a local file system, another thing you can do in Linux. That one I doubt is possible under Windows. Under Linux you can also place an "overlay" file system between the local system and the remote site, so your writes "look and feel" as if they gothe remote site, but are actually maintained locally (because the mount is local). This is especially useful when the remote filesystem is read-only. For example, overlay file systems are often used by the bootable CD Linux systems, so you can have your entire file system on the CD, and you only need a small amount of file space on the local disk for the overlaid write image. When you restart, the overlay can be automatically restored. See why I hate Windows? It's just too hard to have any real fun there. Unless you like Solitaire, of course. What may be more useful to the D build environment is a way to hook in external customized tools. For example, if all accesses to user files could be passed out to a helper app, then that app can use some smarts to decide where to go to get the file: The local disk, the Web, or an FTP site. The easiest way to do that is to virtualize the entire file accesslayer. If POSIX calls are used (instead of native Windows calls), then I can link the D tools with my own POSIX library that has my own snake oil built into it. The calls I don't modify just get passed through to the underlying "real" POSIX library. Windows has a decent POSIX layer, so it should make no difference to local (default) functionality. But it would sure help in adding extra functionality and also in porting the D tools to other environments. -BobC
Jun 12 2002
Lots of good points about Linux filesystems. I, too, am a big fan! However, I think that it's still good to be able to specify an http site in the source because I generally want to put as much as I can into the source files. I don't want proper compilation (if I can avoid it) to involve a user having to install filesystem software and/or configure a bunch of stuff. Frankly, if I could build the executable without a makefile, I'd do that. (D may actually make that feasible...) -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jun 13 2002
Hi,
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D0783D0.6D15127F deming-os.org...
import "http://www.cooperativedevelopment.com/foo.bar.d";
I can't see that such a feature could be useful in any serious project. We
should rather encourage good practices such as configuration control, than
introduce mechanisms like this that can break a project for no good reason.
If resources are on the web - fine. But download them, and put them under
configuration control locally before you use them. Then you will be able to
reproduce your executables when problems arise.
Regards,
Martin M. Pedersen
Jun 13 2002
Thanks Martin. You've hit one of the negatives I was grasping for :) "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message news:aealvn$ner$1 digitaldaemon.com...Hi, "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3D0783D0.6D15127F deming-os.org...reason.import "http://www.cooperativedevelopment.com/foo.bar.d";I can't see that such a feature could be useful in any serious project. We should rather encourage good practices such as configuration control, than introduce mechanisms like this that can break a project for no goodIf resources are on the web - fine. But download them, and put them under configuration control locally before you use them. Then you will be abletoreproduce your executables when problems arise. Regards, Martin M. Pedersen
Jun 13 2002
"Martin M. Pedersen" wrote:Hi, "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3D0783D0.6D15127F deming-os.org...It's a very valid point. Yet I've got this gut feeling that if we included the feature, people down the line would fine new, innovative ways to use it. Just a gut feeling... -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]import "http://www.cooperativedevelopment.com/foo.bar.d";I can't see that such a feature could be useful in any serious project. We should rather encourage good practices such as configuration control, than introduce mechanisms like this that can break a project for no good reason. If resources are on the web - fine. But download them, and put them under configuration control locally before you use them. Then you will be able to reproduce your executables when problems arise. Regards, Martin M. Pedersen
Jun 14 2002
"Martin M. Pedersen" wrote:Hi, "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3D0783D0.6D15127F deming-os.org...When using CVS as a filesystem, you can configure it to do checkouts automatically, when needed, or always. You can also make every write a checkin, and can even use the filesystem cache timeout to minimize traffic into the archive. Even people who have CVS (or any other similar system) generally fail to use it properly. Why? Because it is a hassle to do all the steps all the time. It is far better to automate such drudgery, and the most logical place to put that automation is in the file system. (In the dark ages, it was done with cron scripts that would scan your local files periodically and do the checkins for you.) The more smarts you put in the file system, the less have to be in the application or in your head. -BobCimport "http://www.cooperativedevelopment.com/foo.bar.d";I can't see that such a feature could be useful in any serious project. We should rather encourage good practices such as configuration control, than introduce mechanisms like this that can break a project for no good reason. If resources are on the web - fine. But download them, and put them under configuration control locally before you use them. Then you will be able to reproduce your executables when problems arise. Regards, Martin M. Pedersen
Jun 14 2002