文件列表:

mimefilter\Buffer.h (10643, 2000-04-27)
mimefilter\dlldata.c (847, 2012-09-24)
mimefilter\EULA.txt (1652, 2001-01-02)
mimefilter\ReleaseUMinDependency\regsvr32.trg (22, 2012-09-24)
mimefilter\ReleaseUMinDependency\StdAfx.obj (4969, 2012-09-24)
mimefilter\ReleaseUMinDependency\vc60.idb (50176, 2012-09-24)
mimefilter\ReleaseUMinDependency\xmlmimefilter.exp (1059, 2012-09-24)
mimefilter\ReleaseUMinDependency\xmlmimefilter.lib (1852, 2012-09-24)
mimefilter\ReleaseUMinDependency\xmlmimefilter.obj (48313, 2012-09-24)
mimefilter\ReleaseUMinDependency\xmlmimefilter.pch (5920876, 2012-09-24)
mimefilter\ReleaseUMinDependency\xmlmimefilter.res (3536, 2012-09-24)
mimefilter\ReleaseUMinDependency\XMLMimeFilterPP.obj (20489, 2012-09-24)
mimefilter\resource.h (506, 1998-11-16)
mimefilter\StdAfx.cpp (315, 1998-11-16)
mimefilter\StdAfx.h (955, 1998-11-16)
mimefilter\test.xml (104, 2000-04-25)
mimefilter\xmlmimefilter.aps (3532, 2012-09-23)
mimefilter\xmlmimefilter.cpp (2011, 1998-11-16)
mimefilter\xmlmimefilter.def (234, 1998-11-16)
mimefilter\xmlmimefilter.dsp (9550, 2000-05-01)
mimefilter\xmlmimefilter.dsw (549, 1998-11-16)
mimefilter\xmlmimefilter.h (5752, 2012-09-24)
mimefilter\xmlmimefilter.idl (806, 1998-11-16)
mimefilter\xmlmimefilter.ncb (74752, 2012-09-24)
mimefilter\xmlmimefilter.opt (71680, 2012-09-24)
mimefilter\xmlmimefilter.plg (1628, 2012-09-24)
mimefilter\xmlmimefilter.rc (2896, 1998-11-16)
mimefilter\xmlmimefilter.tlb (1604, 2012-09-24)
mimefilter\XMLMimeFilterPP.cpp (10644, 2012-09-23)
mimefilter\XMLMimeFilterPP.h (2750, 2000-06-22)
mimefilter\XMLMimeFilterPP.rgs (909, 2000-12-28)
mimefilter\xmlmimefilterps.def (255, 1998-11-16)
mimefilter\xmlmimefilterps.mk (526, 1998-11-16)
mimefilter\xmlmimefilter_i.c (1160, 2012-09-24)
mimefilter\xmlmimefilter_p.c (5083, 2012-09-24)
mimefilter\ReleaseUMinDependency (0, 2012-09-24)
mimefilter (0, 2012-09-24)

MIMEfilt - sample MIME filter MIMEfilt.exe is a sample MIME filter for Microsoft Internet Explorer that converts incoming XML data into very simple HTML. This sample demonstrates how to build a simple COM object that filters data of a particular MIME type before it is passed to the client of a URL moniker, such as Internet Explorer. Using MIMEfilt To use MIMEfilt, build the enclosed sample files in Microsoft Visual C++ 6 or later. After the build has automatically self-registered the object, any navigation to XML data in Internet Explorer will invoke the sample and convert the XML to HTML. NOTE: This sample will override the default XML MIME viewer that is built into Internet Explorer. To restore the default XML MIME viewer when you are done with this sample, you can use regsvr32 to unregister XMLMIMEfilter.dll: regsvr32 /u xmlmimefilter.dll Building the Project The current Platform SDK headers and libraries are required to build this sample in Visual C++ 6.0. To ensure that the Platform SDK include and libraries folders have been added to the default include and libraries folder lists in Visual C++, from the Tools menu, click Options, and click the Directories tab. Because of incompatibilities in the Active Template Library (ATL) that shipped with Visual C++ 6.0 with the new Platform SDK headers, the new Platform SDK "ATL30" subfolder must be first in the list. Here is an example order for the include file folders: D:\Program Files\Microsoft Platform SDK\include\ATL30 D:\Program Files\Microsoft Platform SDK\Include D:\Program Files\Microsoft Visual Studio\VC***\Include D:\Program Files\Microsoft Visual Studio\VC***\MFC\Include D:\Program Files\Microsoft Visual Studio\VC***\ATL\Include After a successful build in Visual C++, the protocol will be self-registered and ready to use. Simple Test To test the MIME filter, use the Test.xml file that is included with this project. Simply click Test.xml in Windows Explorer. PLUGGABLE PROTOCOL ARCHITECTURE Registration The registry entries necessary for a pluggable protocol are straightforward and covered well in the main documentation for Pluggable Protocols on the MSDN Web Workshop. All that is required to use MIMEfilt is that XMLMIMEfilter.dll is present on the system and that regsvr32XMLMIMEfilter.dll is run. MIMEfilt uses ATL's simple registration facilities through the .rgs file; open it up and take a peek. The Basics Pluggable Protocols are merely a layer of abstraction in the URL moniker binding process. URL monikers, a COM-based download technology that introduced a new implementation of the well known OLE interface IMoniker, were first seen with the release of Internet Explorer 3.0. URL monikers encapsulate the data retrieval process so that data pulled from an infinite variety of sources and protocols can be retrieved in a generic fashion: ala IMoniker::BindToStorage or IMoniker::BindToObject. This allows a client to reduce all of the complicated code for retrieving any kind of resource via URL to a handful of simple interface calls. Given this goal of providing a seemingly endless number of resources in a very generic fashion, it would seem that URLMON - the Internet Explorer component that implements URL Monikers - must accomplish an almost impossible task. While the built-in code for handling the most common protocols - HTTP and FTP - is implemented by the standard Win32 API, the specific functions needed to retrieve FTP files are very different from the functions needed for HTTP files or especially local files. And for future protocols that might not be implemented by Internet Explorer components directly, the code may be far different. Without a solution, URLMON would have to be recoded and rebuilt for every new protocol scheme, and changes to the handling of one protocol might bubble over to a different one. This is where the Asynchronous Pluggable Protocol (APP) architecture fits into the model. A pluggable protocol is simply an implementation used by URLMON that abstracts the details of retrieving the data from the specific protocol away from the transaction handling functionality of URLMON. Because this implementation has been published for outside developers, anyone can now "plug" a new protocol into Internet Explorer by simply implementing the standard pluggable protocol interfaces. Of course, URLMON implements all of the built-in protocols by using this same technique. Internally, there are pluggable protocols for HTTP, FTP, "file://", and a set of other utility protocols, such as "res://" and "about://". The type of pluggable protocol that handles the retrieval of data for a specific protocol is termed a "protocol handler." MIMEFILT demonstrates a second kind of pluggable protocol, a MIME filter, which is invoked only for certain MIME types. As a middle layer in the bind process, the responsibilities of the MIME filter are very simple. A MIME filter grabs the data from the protocol handler, filters it, and passes it on to the client of the MIME filter, usually the URLMON transaction handler. The protocol handler involved, usually the built-in HTTP protocol handler, does all of the difficult work of getting the data from the remote Web server. The MIME filter delegates most work to the internal protocol handler. The Interfaces The interfaces for an APP are fairly simple and are well documented in the Internet Client SDK. A MIME filter generally implements two main interfaces, IInternetProtocol and IInternetProtocolSink. IInternetProtocol is something of an "external" interface, used by the client of the MIME filter to ask for the data, and IInternetProtocolSink is something of an "internal" progress interface that the protocol handler uses to communicate upwards as it retrieves the data. IInternetProtocol is actually derived from another interface, IInternetProtocolRoot, but currently almost all APPs will want to implement the full meal. The main methods on this interface are Start and Read. URLMON uses IInternetProtocol::Start to initialize the MIME filter, but little else need be done until data is pulled from the MIME filter through IInternetProtocol::Read. At this point, the MIME filter must request data from the protocol handler (a reference to it was handed in during Start), parse that data as it sees fit, and return the requested amount of data back out from its Start method. The remaining IInternetProtocol methods usually just delegate back inward to the protocol handler. For IInternetProtocolSink, the MIME filter's job is equally easy. It is best to just forward these method calls out to the "outgoing" protocol sink that is handed to the MIME filter during the IInternetProtocol::Start call. This communicates back out to the client of the MIME filter. Important Implementation Details * Changing the MIME type - MIME filters can and frequently do change the MIME type of the data they are filtering. You can accomplish this by calling ReportProgress on the outgoing sink and reporting a new MIME type using BINDSTATUS_VERIFIEDMIMETYPEAVAILABLE. Use of the "verified" MIME type status notification will override any MIME type currently sniffed by the protocol handler. The timing of this notification is especially important and should be done late enough to allow the internal protocol handler to finish reporting its MIME type. MIMEFILT reports the MIME type in IInternetProtocol::Read. * File caching may be necessary to solve some problems - Unfortunately, there are many programs and components external to Internet Explorer that require a file on disk in order to work correctly. Almost always, a protocol handler will write its data out to a cache file and return this cache file name up through the interfaces using ReportProgress(BINDSTATUS_CACHEFILENAMEAVAILABLE...). If a MIME filter is brought into the middle of a protocol bind to alter the data returned but the MIME filter does not change this disk file as well, it may appear that the MIME filter is not working in certain situations. The current implementation of XMLMIMEfilter does not alter the cache file. Real-world designs should improve upon this sample by making sure to alter the cache file that is created by the protocol handler. This may be especially important for XML data, as certain usages of the MSXML parser, such as IXMLDOMDocument::Load, may use the disk file created instead of the in-memory buffers passed through Read. DESIGN MIMEFILT is divided into two main classes, CXMLMimeFilterPP and CStringDataBuffer. CXMLMimeFilterPP is a simple ATL-based COM object that implements the two main MIME filter interfaces discussed earlier. CStringDataBuffer is used by CXMLMimeFilterPP to store the data as it is read from the incoming protocol handler and converted by the MIME filter. CStringDataBuffer stores written strings in a linked-list of blocks that are coalesced when a client asks for data through ReadData. This simplifies the buffer handling and data conversion that CXMLMimeFilterPP needs to do. REFERENCES The documentation on pluggable protocols is currently located on MSDN Web Workshop at: http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：