Cart
[Home] [By Thread] [By Date] [Recent Entries]
By transmitting SAX events, I didn't mean sending the whole SAX trace to the destination. That would be size inefficient, as you described. I meant sending SAX events as they occur. By sending SAX events, I mean sending the callback properties. I think, using compression will work good over a slow network, but it will need extra processing at source and destination (which shouldn't be a problem, as these days processing speed is generally fast). On 2/27/08, derek denny-brown <zuligag@g...> wrote: > I'm not sure how you expect serialized SAX events to even come close > to the benefit you would get from compression. XML tends to be highly > compressible, so even ZIP or GZIP tends to get you a significant > benefit at very low cost. Serializing SAX events has the advantage > that parsing is faster, but your concern was size. Since SAX expands > namespaces, a naive serialization of SAX events will often be > significantly larger than the original XML. All of this depends on > what the capabilities of your WAN are. Some studies we did at > AgileDelta demonstrated that on modern hardware, 100Mb is fast enough > that what you want is a fast parser. At 10Mb you want to trade CPU > cycles for compression, since a modern CPU would be waiting on netowrk > I/O. -- Regards, Mukul Gandhi
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
