Why so a low number of methods at WinInetLibrary?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Why so a low number of methods at WinInetLibrary?

Marc Michael
Hello,

I want to create a very small ftp client application. I've looked
around and came up with the WinInetLibrary. But why there are no entry
points for the functions of the underlying dll? Even
InternetCloseHandle() is not available. Only 4 methods are defined. Is
there perhaps a better way to work with ftp servers and nobody needs
this library, or I have to add the methods I need by myself?

I only want to check if a specific file is available on a specific ftp
server and, if so, retrieve the following file information:

 * file size
 * creation date of the file

I don't want to download the file.

I am using Dolphin 6.0.2.

Regards,
Marc Michael


Reply | Threaded
Open this post in threaded view
|

Re: Why so a low number of methods at WinInetLibrary?

Matias Maretto
Michael: hello. Long ago...  Very long ago, I've made a small ftp
client. It uses the Object: Socket and ServerSocket. I think in this 2
object you've got all you need to access and FTP server.
If you want I can send you the package.


Reply | Threaded
Open this post in threaded view
|

Re: Why so a low number of methods at WinInetLibrary?

Chris Uppal-3
In reply to this post by Marc Michael
Marc,

> I want to create a very small ftp client application. I've looked
> around and came up with the WinInetLibrary. But why there are no entry
> points for the functions of the underlying dll?

I think it's just that nobody at Object Arts has happened to need WinInet for
anything more than the very simple use in the Dolphin Update process.   So
they've never added any other features from that library.

In general Dolphin does not attempt to provide a complete wrapper for all the
Windows APIs. There is no point (there are far too many to do properly, and if
badly or incompletely done, then that's no real help to anyone[*]).  It does
include properly crafted wrappers for important "chunks" of functionality,
Socket, GUI, XML, ODBC, etc, etc, but doesn't go out of its way to cover
everything that MS have ever come up with.

So, you get Sockets, but not WinInet.  If you want WinInet then you'll have to
do it yourself.

I suspect also that there hasn't been much push from customers to have this
/particular/ library exposed more completely.  Rather a lot of us distrust
and/or dislike the MS networking code, and would rather use our own or a
third-party's.

    -- chris

([*] If you are capable of understanding the raw Windows APIs, and of using
them to write code that works, then you are certainly capable of the relatively
trivial task of adding the low-level wrapper code to Dolphin.  If, on the other
hand, you are not capable of using the raw Windows APIs effectively, then you
wouldn't gain anything from having (only) a low-level wrapper available.  You'd
need a high-level wrapper which was properly designed to hide all the Windows
mess -- but that takes time and effort, /lots/ of time and effort)


Reply | Threaded
Open this post in threaded view
|

Re: Why so a low number of methods at WinInetLibrary?

Marc Michael
Chris Uppal schrieb:

> Marc,
>
> > I want to create a very small ftp client application. I've looked
> > around and came up with the WinInetLibrary. But why there are no entry
> > points for the functions of the underlying dll?
>
> In general Dolphin does not attempt to provide a complete wrapper for all the
> Windows APIs. There is no point (there are far too many to do properly, and if
> badly or incompletely done, then that's no real help to anyone[*]).  It does
> include properly crafted wrappers for important "chunks" of functionality,
> Socket, GUI, XML, ODBC, etc, etc, but doesn't go out of its way to cover
> everything that MS have ever come up with.

Ok, that's a good point. Especialy your foot note. Most C-Compilers for
Windows comes with all Headerfiles for the important Libraries. But
they lack on more high level frameworks. Dolphin on the other side
lacks some ready to use "Core Library Functions", but provides a good
high level framework on the functions it provides.
For example: In C you have all the base socket functions. But this
functions only provide the function to send Bytes through a socket. At
Dolphin, you have a real Socket-Class. This Class provides the
functionality to simply move full objects through a socket.

And yes, if you want to access a function inside a Library, it's very
easy to implement. The framework of Dolphin to access dlls is very easy
to use.

But high level frameworks have often a problem: If something is not
normal, I must leave the framework. I've created an application in
Rebol which solves the problem, but encountered a problem. Example
Code:

file-information: info?
ftp://user:[hidden email]/filename.txt

After this line, "file-information" would hold an object which
represents the information of the file, like creation date, file size
and so on. The problem was, that the specific ftp host, I want to use,
is extremly slow at answering. Rebol breaks with a "time out error".
So, where I have to look to raise the time to wait for an answer? Here
is the point where I have to leave the nice high level framework.

So, this example shows, that it is not easy to write an easy to use,
all cases stable high level framework.

> I suspect also that there hasn't been much push from customers to have this
> /particular/ library exposed more completely.  Rather a lot of us distrust
> and/or dislike the MS networking code, and would rather use our own or a
> third-party's.

All in Smalltalk has an advantage, of course.

Ok, I must admit, the Dolphin way is correct. Too many frameworks in
the core image would distract the product. But what about additional
packages?

Someone started a thread some day earlier, why there's no support on
the web for Dolphin. I think, the most problem is time. I want to
create applications, I don't want to write books, say webpages. So,
what about a public reposity, which is directly accessable from
Dolphin? Like CPAN or the Reb from Rebol?

Ok, I've more written than I wanted.

>
>     -- chris
>
> ([*] If you are capable of understanding the raw Windows APIs, and of using
> them to write code that works, then you are certainly capable of the relatively
> trivial task of adding the low-level wrapper code to Dolphin.  If, on the other
> hand, you are not capable of using the raw Windows APIs effectively, then you
> wouldn't gain anything from having (only) a low-level wrapper available.  You'd
> need a high-level wrapper which was properly designed to hide all the Windows
> mess -- but that takes time and effort, /lots/ of time and effort)

This is a good text. This is one of the important points, which gives
me the answer to my question. Thank you very much.

Best regards,
Marc Michael