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))) ]

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))) ]
>
>

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

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

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))) ]

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

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

"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))) ]

"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