gecko-dev/uriloader/base/nsIURILoader.idl
dougt%netscape.com 128f95aa9b Relanding Necko Changes.
Revising nsIChannel to allow for overlapped i/o. This consists of three parts:

1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.

This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.

r=darin@netscape.com
sr=rpotts@netscape.com
2001-02-21 20:38:08 +00:00

128 lines
4.9 KiB
Plaintext

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 4 -*-
*
* The contents of this file are subject to the Netscape Public
* License Version 1.1 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.mozilla.org/NPL/
*
* Software distributed under the License is distributed on an "AS
* IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
* implied. See the License for the specific language governing
* rights and limitations under the License.
*
* The Original Code is mozilla.org code.
*
* The Initial Developer of the Original Code is Netscape
* Communications Corporation. Portions created by Netscape are
* Copyright (C) 1999 Netscape Communications Corporation. All
* Rights Reserved.
*
* Contributor(s):
*/
/* The uri dispatcher is responsible for taking uri's, determining
the content and routing the opened url to the correct content
handler.
When you encounter a url you want to open, you typically call
openURI, passing it the content listener for the window the uri is
originating from. The uri dispatcher opens the url to discover the
content type. It then gives the content listener first crack at
handling the content. If it doesn't want it, the dispatcher tries
to hand it off one of the registered content listeners. This allows
running applications the chance to jump in and handle the content.
If that also fails, then the uri dispatcher goes to the registry
looking for the preferred content handler for the content type
of the uri. The content handler may create an app instance
or it may hand the contents off to a platform specific plugin
or helper app. Or it may hand the url off to an OS registered
application.
*/
#include "nsISupports.idl"
interface nsIURIContentListener;
interface nsIURI;
interface nsILoadGroup;
interface nsIDocumentLoader;
interface nsIProgressEventSink;
interface nsIChannel;
interface nsIRequest;
interface nsIStreamListener;
interface nsIInputStream;
typedef long nsURILoadCommand;
[scriptable, uuid(40AECB53-8B65-11d3-989D-001083010E9B)]
interface nsIURILoader : nsISupports
{
/* as applications such as messenger and the browser are instantiated,
they register content listener's with the uri dispatcher corresponding
to content windows within that application.
Note to self: we may want to optimize things a bit more by requiring
the content types the registered content listener cares about.
*/
void registerContentListener (in nsIURIContentListener aContentListener);
void unRegisterContentListener (in nsIURIContentListener aContentListener);
/* OpenURI requires the following parameters.....
aURI --> the uri you wish to open
aCommand --> describes the context of the url. most often, you want to pass viewNormal here.
but if it the action was from a user click or you want to view source, or you want
a new window, these are all passed in via aCommand.
aWindowTarget -> the name of the desired target window (can be null)
aWindowContext --> if you are running the url from a doc shell or a web shell,
this is your window context. If you have a content listener
you want to give first crack to, the uri loader needs to be able
to get it from the window context (we'll use nsIInterfaceRequestor).
we will also be using nsIInterfaceRequestor to get at the progress event
sink interface.
aReferringURI --> if a uri referral was involved....
*/
void openURI(in nsIChannel aChannel,
in nsURILoadCommand aCommand,
in string aWindowTarget,
in nsISupports aWindowContext);
/* same call as OpenURI except this one takes an IP address to use as well...
adapterBinding -> the local IP address to bind to*/
void openURIVia(in nsIChannel aChannel,
in nsURILoadCommand aCommand,
in string aWindowTarget,
in nsISupports aWindowContext,
in unsigned long adapterBinding);
/* stops an in progress load */
void stop(in nsISupports aLoadCookie);
/* dirty little back door for sneaking the load group out in case you need
it to create the channel before calling openURI */
nsILoadGroup getLoadGroupForContext(in nsISupports aWindowContext);
nsIDocumentLoader getDocumentLoaderForContext (in nsISupports aWindowContext);
/* these are nsURILoadCommand */
const long viewNormal = 0;
const long viewUserClick = 7;
const long viewNormalBackground = 0;
/* mscott -> I'm going to move this out into a separate private interface
*/
void dispatchContent(in string aContentType,
in nsURILoadCommand aCommand,
in string aWindowTarget,
in nsIRequest aRequest,
in nsISupports aCtxt,
in nsIURIContentListener aContentListener,
in nsISupports aSrcWindowContext,
out string aDesiredContentType,
out nsIURIContentListener aTargetListener,
out boolean abortDispatch);
};