www.digitalmars.com         C & C++   DMDScript  

D - import http...

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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
next sibling parent "Matthew Wilson" <dm synesis-group.com> writes:
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
prev sibling next sibling parent reply "Robert W. Cunningham" <rcunning acm.org> writes:
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
next sibling parent "Matthew Wilson" <dm synesis-group.com> writes:
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:

 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

 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
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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
prev sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
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
next sibling parent "Matthew Wilson" <matthew thedjournal.com> writes:
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...
     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

 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

 reproduce your executables when problems arise.

 Regards,
 Martin M. Pedersen

Jun 13 2002
prev sibling next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Martin M. Pedersen" wrote:

 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

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))) ]
Jun 14 2002
prev sibling parent "Robert W. Cunningham" <rcunning acm.org> writes:
"Martin M. Pedersen" wrote:

 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

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. -BobC
Jun 14 2002