Re: Ada.Directories problems, a summary

[Ivan Levashew <octagram@bluebottle.com>]

Dmitry A. Kazakov wrote:
>
> > Ada RTL isn't enough (and wasn't ever) to do anything serious.
>
> I hope running Ada programs qualifies as serious. (:-))
>
Serious Ada programs use big amount of non-RTL libraries.

>
> Nope, Ada RTL must support design of platform-independent applications. Any
> OS-specific library has no use in my eyes. I think there is a broad
> understanding of this beyond Ada community.

I was talking about OS-specific implementation. Existence of
fallback implementation makes library 100% portable.

> As an example consider GTK
> introducing GIO library which tries to abstract the I/O OS layer.

Yes, I meant something like this (more precisely, I had NSPR
in mind).

> > Read word by word a file,
>
> I don't see any problem with that. Ada.Streams.Stream_IO should do it.

I was thinking Modula-2's text API vs. Ada's one. Both
are advanced, but I can hardly remember when was the last
time I needed Ada's Page, Set_Line, etc. stuff.

> > which is stored in a zip file,
> > which itself is hosted on an FTP server,
> > which is being accessed through a SOCKS5 proxy,
> > which is being accessed through an HTTPS proxy (CONNECT method),
> > which is being accessed directly.
>
> All these are just not files. It is a UNIX-world aberration that everything
> must be a file. Everything is nothing.
I don't care about UNIX convention. There are abstraction like
"sequence of octets", "ability to establish connection with",
etc., and I'd like to deal with these abstractions and not with
what particular cases OS designers gave me instead.

> > Every part of Ada RTL and GNAT RTL is locked down to immediate
> > filesystem/immediate network connectivity.
>
> Which is good, because your list has no end. What about CORBA, DB
> connections etc?
The point isn't about CORBA and FTP. The point is about
indirection. As soon as one has libraries for FTP/ZIP/SOCKS5,
one should have opportunity to do what I've said.

Currently, Ada RTL is designed in a way that one has to write
text API implementation from scratch.

> The option is to limit it to files.
A programming language of software engineers shouldn't
have stupid limitations like this.

> Later on URI schemes could added in a set of separate
> packages and so on.

URI scheme parser is not a major part. URI is bad for accessing
multivolume archives, cryptography-enabled SFTPs and so on.