Using Asynchronouse Pluggable Protocols

  • Thread starter Thread starter Fredo
  • Start date Start date
F

Fredo

I was hoping I could do something like:

WebRequest req = new WebRequest("mk:whatever") to retrieve HTML help topics
via the mk: protocol. But it appears that http: and file: are the only
supported protocols.

How would one retrieve data via another asynchronous pluggable protocol
under .NET?

Pete
 
Fredo,

You won't be able to do it in .NET through the WebRequest. Rather, you
will have to call the CreateMoniker API through the P/Invoke layer, and then
make the calls to load through the methods on the IMoniker implementation
returned (through COM interop of course).

Hope this helps.
 
Nicholas,

I was afraid that was going to be the case.

Do you have any idea why this isn't the way WebRequest works to begin
with? I mean, wouldn't it be more "general" that way? On top of which, it
could truely make asynch pluggable protocols much more accessible and
useful.

Pete

Nicholas Paldino said:
Fredo,

You won't be able to do it in .NET through the WebRequest. Rather, you
will have to call the CreateMoniker API through the P/Invoke layer, and then
make the calls to load through the methods on the IMoniker implementation
returned (through COM interop of course).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Fredo said:
I was hoping I could do something like:

WebRequest req = new WebRequest("mk:whatever") to retrieve HTML help
topics
via the mk: protocol. But it appears that http: and file: are the only
supported protocols.

How would one retrieve data via another asynchronous pluggable protocol
under .NET?

Pete
Click to expand...
Click to expand...
 
Pete,

I think that they wanted to reduce dependency on COM, as well as make it
more of a component that could be used in server side situations. As nice
as the APPs are, they aren't meant for use in server situations (the handler
for HTTP uses WinInet ultimately, for example).

It should be possible to perform some sort of mapping though, it would
just require some work.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Fredo said:
Nicholas,

I was afraid that was going to be the case.

Do you have any idea why this isn't the way WebRequest works to begin
with? I mean, wouldn't it be more "general" that way? On top of which, it
could truely make asynch pluggable protocols much more accessible and
useful.

Pete

in
message news:[email protected]...
Fredo,

You won't be able to do it in .NET through the WebRequest. Rather, you
will have to call the CreateMoniker API through the P/Invoke layer, and then
make the calls to load through the methods on the IMoniker implementation
returned (through COM interop of course).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Fredo said:
I was hoping I could do something like:

WebRequest req = new WebRequest("mk:whatever") to retrieve HTML help
topics
via the mk: protocol. But it appears that http: and file: are the only
supported protocols.

How would one retrieve data via another asynchronous pluggable protocol
under .NET?

Pete
Click to expand...
Click to expand...
Click to expand...
 
Thanks for the help. As always, you're a great source of information.

I'll tell you, what kind of irks me is that APPs can provide a great deal of
power. If you look at how KDE manages them, for example, it has a really
easy to use and flexible architecture for dealing with URLs and there are a
lot of applications that take advantage of the facility. I just think it
could be equally useful in .NET if it were easier to use.

Pete

Nicholas Paldino said:
Pete,

I think that they wanted to reduce dependency on COM, as well as make it
more of a component that could be used in server side situations. As nice
as the APPs are, they aren't meant for use in server situations (the handler
for HTTP uses WinInet ultimately, for example).

It should be possible to perform some sort of mapping though, it would
just require some work.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Fredo said:
Nicholas,

I was afraid that was going to be the case.

Do you have any idea why this isn't the way WebRequest works to begin
with? I mean, wouldn't it be more "general" that way? On top of which, it
could truely make asynch pluggable protocols much more accessible and
useful.

Pete

in
message news:[email protected]...
Fredo,

You won't be able to do it in .NET through the WebRequest. Rather, you
will have to call the CreateMoniker API through the P/Invoke layer, and then
make the calls to load through the methods on the IMoniker implementation
returned (through COM interop of course).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I was hoping I could do something like:

WebRequest req = new WebRequest("mk:whatever") to retrieve HTML help
topics
via the mk: protocol. But it appears that http: and file: are the only
supported protocols.

How would one retrieve data via another asynchronous pluggable protocol
under .NET?

Pete
Click to expand...
Click to expand...
Click to expand...
 
Pete,

I've toyed around with the idea of creating a WebRequest/WebResponse
based class which would use the APP architecture to get what it needs. I
always thought it would be rather useful (more neat than useful).

Perhaps I'll look into it again, because of this post.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Fredo said:
Thanks for the help. As always, you're a great source of information.

I'll tell you, what kind of irks me is that APPs can provide a great deal
of
power. If you look at how KDE manages them, for example, it has a really
easy to use and flexible architecture for dealing with URLs and there are
a
lot of applications that take advantage of the facility. I just think it
could be equally useful in .NET if it were easier to use.

Pete

in
message news:%[email protected]...
Pete,

I think that they wanted to reduce dependency on COM, as well as make it
more of a component that could be used in server side situations. As
nice
as the APPs are, they aren't meant for use in server situations (the handler
for HTTP uses WinInet ultimately, for example).

It should be possible to perform some sort of mapping though, it
would
just require some work.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Fredo said:
Nicholas,

I was afraid that was going to be the case.

Do you have any idea why this isn't the way WebRequest works to begin
with? I mean, wouldn't it be more "general" that way? On top of which, it
could truely make asynch pluggable protocols much more accessible and
useful.

Pete

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote
in
message Fredo,

You won't be able to do it in .NET through the WebRequest.
Rather,
you
will have to call the CreateMoniker API through the P/Invoke layer,
and
then
make the calls to load through the methods on the IMoniker implementation
returned (through COM interop of course).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I was hoping I could do something like:

WebRequest req = new WebRequest("mk:whatever") to retrieve HTML help
topics
via the mk: protocol. But it appears that http: and file: are the only
supported protocols.

How would one retrieve data via another asynchronous pluggable protocol
under .NET?

Pete
Click to expand...
Click to expand...
Click to expand...
 
Back
Top