@Katja Bergman said:
We've seen so
many bare breasts here that no one really gets excited over them.
Speak for yourself :-P
@Katja Bergman said:
We've seen so
many bare breasts here that no one really gets excited over them.
@sas said:
In the upper-right corner of Firefox, there is a circle of gray dots
(which spin when the browser is working). Just to the left of
this, a symbol appears when updates are available. You can click
on it to get them.
@CPound said:
Ok, here's the deal on "secret police". We do
indeed have freedom of speech and writing in the US. You just can't be
stupid about it. Why on earth would you press the envelope by
saying/publishing anti-government slogans during a time of
international crisis and terrorism? Like the Dixie Chicks for example.
What the !@#$ were they thinking? That was
just moronic. You can say/write what you want, but c'mon, be smart and
loyal to the country you live in. If you don't like it you can always
leave. No one is keeping you here.
I think you'll find that a lot of european countries take a slightly
different view of "freedom of speech". They tend to not tolerate
racism, incitement to violence etc. but will allow most anybody to
disagree with their government in public, using pretty much any
language they like. The people in europe also tend to not get
upset by a bare breast on national TV :-)
Europeans (sweeping generalisation) think that it's stupid to shut
people up just because they have different opinions, and to let hate
and violence spread through the country. And they like breasts.
@Katja said:
How many lines of code would you need to write "Hello,
World." on your screen in Assembler? It's not the number of lines that
matter. You're typically a guy, you think size matters... [:P]
I don't quite see your point here. Why do you think assembler
isn't the most popular language? We need code that's easy to read and
write. SOAP is neither (though I grant that it could be worse).
Personally, I think using SOAP for the google API is just
overkill. Did you notice that they still support a much easier API for
RPC, but that that one is only available for paying customers?
Besides, we're on a network here, so size does
matter. You could probably gzip the body of the request and responses,
though I'm not sure if that's supported by the available soap
implementations.
@Katja said:
@joodie said:depending on the kind of data returned, XML might be a good choice, however...
Yea, but basically you need some kind of protocol that tells the server it should return something as XML instead of HTML or whatever. SOAP is such a protocol. By wrapping things in a SOAP envelope it becomes much clearer to the server about what to do with some request. The URL itself tells where it should be delivered and the envelope itself provides the required information that is required at that point. The server itself doesn't have to know anything about SOAP. It just needs to know how to pass it on.
HTTP headers should already tell you what type of data you're getting. SOAP just ignores most of the possibilities of HTTP.
A SOAP URL and most of the HTTP headers don't determine much in
SOAP, and a lot of information that should be passed via HTTP headers
(if only to get possible proxies to work correctly) need to be
specified in the SOAP envelope too. One URL can be coupled to a hundred
different endpoints. Besides, I was talking about data returned.
IMO it's much cleaner to have more or less descriptive URLs and
matching headers for different requests. But then, I like REST.
@Katja said:
@joodie said:CSV data is not as easy to parse as most people think, but XML is a lot harder - that's why we have code libraries. Anyway, if you have data that is obviously just a list of records, using CSV will dramatically reduce the amount of network traffic and time spend parsing the result.The problem with CSV is when you have to deal with different kind of data records. Say, for example, that you're trying to send an invoice from client to server. One client who orders several things at the same time and who gets a discount calculated over the whole amount. You'd need to tell in some way who the client is, the items he ordered, the quantity of every item he ordered, the price for each item perhaps and of course the discount that he gets. And maybe a few more things too. Try to fit that in a single CVS file.
That's why I said "if you have data that is obviously just a list of records".
@Katja said:
The SOAP standard is pretty new, although it has taken a while before it became a standard. I think SOAP became a standard in 2002 or 2003 or so. Before that, several SOAP implementations already existed but it wasn't a full standard yet.
I didn't know that. That might indeed explain a few things.
What? You mean some people don't use their real picture as an avatar? :-)
@Katja Bergman said:
>
Simple question. Do you have any better solution then? Basically, SOAP
is nothing more than a simple protocol so a client application can
exchange data with a server application through simple HTTP messages.
The best thing of SOAP is that you basically only need an HTTP server to use it. It's not platform-specific, it's not processor-specific. And it's an open standard.
SOAP might be slow in your opinion, but basically it's just a webbrowser-technique for applications, instead of a webbrowser for people.
Sure, you could send the data over as simple HTML pages but then you often send more that you really need in the client.
Or send it over as a plain comma-separated text format. Or whatever other cryptic text format has your preference. Just makes it a lot harder for the client and server to communicate with one another since they both have to be able to read that format.
No, the problem with SOAP is that people have these huge tables with 10.000 records inside and they want to send over all 10.000 records to the client. Now, THAT will slow it down considerably. But any client-server technique will slow down because this kind of stupidity. It is okay for a simple desktop application to just select everything and show it to the user, but in client-server applications, this is plain stupid.
Now, SOAP can be a pretty fast solution, and also reasonable easy to implement with the right tools. Unfortunately it's a new standard. As a result, some companies create tool that supposedly support SOAP but they don't follow the standard or it's full with bugs.
Yes, SOAP is crap.
It's not simple, it's not object-oriented, not extensible, slow, way
too complicated for what it tries to achieve, it tries to re-invent HTTP on top of HTTP and it's hard to debug. Plus WSDL
hardly ever works out of the box when you use 2 different
implementations.
It seems to me just about the worst combination of HTTP, XML and RPC anyone could have imagined.
In other words, it's about as crappy as the XML DOM, and like the DOM,
the only thing for it, is that it's more or less standard and
cross-language.
It looks a lot better, but now I can't enter HTML code directly anymore!