Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi, We have also to consider that the transport mechanism can provide compression. HTTP has already this unused feature. I made some tests with HTTP 1.1 and compression transport and got for any text transport some improvements. Because the compression is taken care in the transport layer, the XML parser receives a document as usual. When I probed the mechanism further here is what's happening in IE (Currently we are working on a paper for new architecture for Mozilla Netlib). IN IE 5.x the server sends the data in HTTP 1.1 compressed mode. the client receives the data in compressed mode, then for each 8K chunks calls a MIME filter that does the decompression. After the decompression is done by the MIME filter, the transaction handler give the chunks to the document handler and therefore to the parser. In Mozilla we do not have this intermediary step. The transaction handler deals only with a protocol handler and a MIME filter is missing. To be more versatile and be able to process the stream adequately we have to add the notion of filters. So, as already mentioned in Simon's XML architecture we can say that browsers implements some parts of the layers like: a) transaction processing b) MIME filtering (compression, decryption, etc...) c) Document handling routing So in a browser's architecture we have: Transaction handler ----> Protocol handler -----> MIME filter------> Document manager ------> document handler (here you find the XML parser) In IE, these elements are already independant of the browser and are encapsulated in a module called UrlMon. basically, you provide a display name like "http://www.netfolder.com/ and urlmon act as a transaction handler, calls the MIME filters and give you the data. In Mozilla new Gecko architecture this is also a separate XPCOM module named Netlib. You also provide a display name, the module act as a transaction handler, calls the right protocol hanlder and give you the data (encrypted, uncompressend, etc). There is work in progress to add the notion of MIME filters. Both module share a similar kind of interface based on COM. This simply means that an object can have multiple interface and that a Query interface mechanism is available to obtain the right one. So Mozilla XPCOM and Microsoft COM implementations are very similar. Both kind of objects have binary signatures in the form of a C++ pure virtual interface. Both interfaces have mendatory members like AddRef, Release and QueryInterface. The difference being the way you instanciate objects and how they are registered. But, in both cases, the transaction manager and its helper modules: protocol handlers and MIME filters are accessible to other applications than browsers. There is also an other thread of evolution named HTTP NG. As you know, HTTP is like an remote object with Get, Put, Post, Delete methods. WebDav (already implemented in IE 5.x WebFolders) recently added PROGET, PROPUT, etc.... HTTP NG intents is to be able to create any kind of objects and the actual HTTP 1.1 (WebDav) being one type of object: a Document object. So, with HTTP NG, you'll be able to create your own object. This means that the evolution of HTTP on one side and XML on the other side is creating a concurrent to OMG. Here's why: OMG as already mentioned in this list is a middleware with: a) an interface language that could be mapped to different languages for concrete implementation b) a marshalling format for object communication. So, here is what's happening in the Web world: a) the interface definition language is still absent and it could be OMG IDL. But today, no choices has been made on this. We'll need some more work on the HTTP NG front before this happens. But when this will happens, the web will be a web of diverse distributed objects and not solely distributed documents. b) the marshalling format is becoming more and more XML. However the drawback for XML is that it is wasting a lot of transport bandwidth compared to other more efficient formats. To palliate that, the transport layer tries to use compression to reduce the packets payloads. HTTP 1.1 already provides this, but this is not used very often (if not at all). As you know, things are moving slowly. In the next 3 to 4 years, most browsers in the field will support HTTP 1.1 and compression (about 65% does today). The worst case is server side where a lot of improvised servers are not well configured to support adaptative compression negociation even if they can. This is mainly a knowledge barrier and not a technical issue. but in some years form now, compressed transport will be the de facto way. This was my Sunday morning .2 cents. Regards Didier PH Martin mailto:martind@n... http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
