What is the difference between rss and json?
My knowledge is that these two are all data support(feed info)..
I want to know advantages and disadvantages of using these two and
performance between these two?
Which one is better for android?
RSS (Rich Site Summary) and JSON (JavaScript Object Notation) are the
program-readable formats of data. Web publishers make these feeds so
their content will be easily accessible for re-use.
The difference between RSS and JSON really lie in how they are parsed.
Although they are both strings (RSS is essentially just plain-text
XML), JSON is far lighter-weight than RSS. Even though RSS is
plain-text, it will still have to be parsed/traversed in a
DOM/ElementTree similar to how one would read raw HTML data. As you
can imagine this can be a big pain. JSON is a string that can be
easily evaluated into a JavaScript object and traversed naively.
Another big advantage to JSON over RSS is that you can read it
remotely using JSONP, whereas RSS blocks cross-domain requests. This
means that you would have to use a programming language which operates
on the server's side (e.g. PHP/Ruby/Python) in order to download that
page as a proxy and then parse it.
Source.
JavaScript can't read RSS feeds from remote sites, so you're limited to your own domain. JSON, however, works cross-domain. Its the biggest one.
Another is,
The difference between RSS and JSON really lie in how they are parsed. Although they are both strings (RSS is essentially just plain-text XML), JSON is far lighter-weight than RSS. Even though RSS is plain-text, it will still have to be parsed/traversed in a DOM/ElementTree similar to how one would read raw HTML data. As you can imagine this can be a big pain. JSON is a string that can be easily evaluated into a JavaScript object and traversed naively.
Related
I'm learning about API's, I came across the fact that web services always return either XML or JSON data.
Why those specific languages?
Although the most common, web services can return anything over a HTTP stream binary data, string data, video streams etc. XML and JSON are just very popular for returning data.
XML and JSON are not languages. They are structures in which data can be returned. Both have the advantage of being (just about) human readable, and of containing enough meta information to make sense of the returned data, and are flexible enough to store a complex object. The key is often "serialization" - a programming language builds an object, the object is serialized as XML or JSON, and the serialzied representation returned.
XML and JSON aren't languages, rather they are different approaches to sending structured data.
Languages, such as Javascript, C#, and Python (and hundreds more) can read data when it is structured in either JSON or XML.
XML was invented first and quickly lost popularity when JSON came onto the scene as it's easier to use. But XML still has some good features that some people can't live without, and XML is used by older systems so still supported for legacy's sake.
Use google and do searches around JSON v XML to understand more, but don't get dragged into the argument.
Both represent data, JSON is more popular and easier to understand.
Simplest and structured way to define data over the XML and Json. And Mostly all the programming language can support parsing both XML and Json. The way both XML and Json reading,writing also faster compare to other file structure.
I have a Qt TCP Server and Client program which can interact with each other. The Server can send some function generated data to the socket using Qtextstream. And the Client reads the data from the socket using simple readAll() and displays to a QtextEdit.
Now my data from Server side is huge (around 7000+ samples ) and I need the data to appear on the Client side instantaneously. I have learned that using XML will help in my case. So, I made an Qt XML Server and it generates the whole xml data into a .xml file. I read the .xml file in Client side and I can get to display its contents. I used the DOM method for parsing. But I get the data to display only when all the 7000+ samples have been generated on the Server side.
I need clarifications on these questions:
How do I write each element of the XML Server side in to a String and send them through socket? I learnt tagName() can help me, but I have not been able to figure out how.
Is there any other way other than the String method to get a single element generated in the Server side to appear in the Client side.
PS: I am a newbie, forgive my ignorance. Thank you.
Most DOM XML parsers require a complete, well-formed XML document before they'll do anything with it. That's precisely what you see: your data is processed only after all of the samples have been received.
You need to use an incremental parser that doesn't care about the XML document not being complete yet.
On the other hand: if you're not requiring XML for interoperability with 3rd party systems, you're probably wasting a lot of resources by using it. I don't know where you've "learned" that XML will "help in your case". To me it's not learning, it's just following the crowd without understanding what's going on. Is your requirement to use XML or to move the data around? Moving data around has been a well understood problem for decades. Computers "speak" binary. No need to work around it, you know. If all you need is to move around some numbers, use QDataStream and be done with it. It'll be two orders of magnitude faster than the fastest XML parsers, you'll transmit an order of magnitude less data, and everyone will live happily ever after*.
*living happily ever after not guaranteed, individual results may vary.
Our program currently uses the libxml2 DOM API (xmlReadFile) to load an entire file into memory. Unfortunately, this breaks down on "large" XML files, as the basic memory consumption of libxml2 DOM is about 4-5 times the base file size.
It seems libxml2 offers two APIs for reading XML when I don't want to store the whole tree in memory: SAX2 and xmlReader.
I haven't dug into the APIs yet, but I'm wondering which one is preferable under which circumstances?
Note: All I need to do with the XML file is populate some C++ datastructures with the data found in the XML file. And these will in turn be a lot smaller than the (very verbose) XML definition. At the moment, with xmlReadFile and the DOM API the process takes about 100MB memory for a 20MB XML file. The C++ data in memory for such a file is more like 5MB -- so I could go from 1:4 to 4:1, which would already help a lot.
I follow this approach, if the processing is sparse (need only an element here and there) xmlReader is better, if you need to process all elements, SAX is better. Although, opinion could come in to play as to whether you want to push the processing or you want the processing to push your code...
If you need to process large XML documents then size becomes the primary consideration. As you saw with 20MB -> 100MB for DOM parsing, if you get much larger than this that can be prohibitively expensive and SAX may be the only way to process it. For embedded or memory constrained devices SAX may be required even for small files.
If you want to start parsing before the file is complete SAX is the way to go. If you are writing a browser, are streaming XML, or require responsiveness then you will need to use SAX.
SAX is more of a pain, if you can get away with DOM parsing that will usually lead to less code and simpler code, for simpler DOM queries you can avoid a state machine for example. If you only care about a handful of fields in the document you could even avoid querying a DOM parser directly and query XSLT instead.
We're using XTK to display data processed and created on a server. In our particular case, it's a parallel isocontouring application. As it currently stands we're converting to the (textual) VTK format and passing the entire (imaginary) VTK file over the wire to the client, where XTK renders it. This provides some substantial overhead, as the text format outweighs in the in-memory format by a considerably amount.
Is there a recommended mechanism available for transmitting binary data directly, either through an alternate format that is well-described or by constructing XTK primitives inside the JavaScript code itself?
It should be supported to parse an X.object from JSON. So you could generate the JSON on the serverside and use the X.object(jsonobject) copy constructor to safe down cast it. This should also give the advantage that the objects can be 'webgl-ready' and do not require any clientside parsing which should result in instant loading.
I was planning to play with that myself soon but if you get anything to work, please let us know.
Just have in mind that you need to match the X.object structure even in JSON. The best way to see what is expected by xtk is to JSON.stringify a webgl-ready X.object.
XMLHTTPRequest, in its second specification (the last one), allows trans-domain http requests (but you must have the control of the php header on the server side).
In addition it allows to sent ArrayBuffer, or Blobs or Documents (look here). And then on the client side you can write your own parser for that blob or (I think it fits more in you case) that BinaryBuffer using binary buffer views (see doc here). However XMLHTTPRequest is from client to server, but look HTML5 WebSocket, it seems it can transfert binaryArrays too (they say it here : ).
In every case you will need a parser to transform binary to string or to X.object at the client side.
I wish it helped you.
This application runs on an embedded platform with low processing power and memory. I want to produce huge XML from the application. Currently I am constructing DOM and serializing into XML using Xerces-C++ 3.1.1. But the DOM construction takes long time and consumes lot of memory.
I know SAX is lightweight approach of parsing XML compared to DOM. Like that is there a lightweight approach for producing XML? Ofcourse I can produce the XML by concatenating strings but I didn't choose that approach because I want to make sure I produce a well-formed XML and sanitize the texts I include in it.
What you are looking for is normally called streaming serialization where parts of the document are written out as they become available instead of accumulation them all and writing them out at the end (which is what the DOM approach entails).
Xerces-C++ does not currently have streaming serialization support. But it is not very difficult to emulate it using DOM. The idea is to construct a DOM document fragment when a chunk of your data is ready to be serialized, write it out using the DOMWriter API, and free it once done. When you have another chunk ready, repeat the above steps. The result is an application that uses only a fraction of the memory that would be required to create the complete document.
We use this approach in CodeSynthesis XSD, an XML data binding toolkit for C++, to be able to handle XML documents that are too big to fit into memory. In fact, we have written some helper classes that simplify all this and wich you can find as part of the 'streaming' example in the examples/cxx/tree/ directory (the example code is public domain so feel free to borrow it ;-)).