Probably google doing that cut-the-bottom-5% thing.
Recently, I was forced to realize the importance of a collation call-out (or lack thereof) in a MSSQL query in PHP.......
Ok, my current project requires...
Yea, definitely should have stayed put ;)
For those that dont speak in acronyms:
In other news... fucking bittorrent. It's apparently pretty hard to block these days. OpenWRT has some capabilities, but not enough. :-(
(Normally, I wouldn't care, but there are some people in our share house who haven't gotten the message that if they keep leeching, we're going to lose our internet access.)
Sandvine has the right idea, but is priced out of reach.
If you have the privilege of being the BOFH firewall admin, perhaps it's time to capture all port 80 traffic and send it to a nazi-proxy.
Although just yesterday I found out about a project we're having trouble testing because our old vax which this project has to interface with can only accept 3 letter codes to denote a client whereas all our new clients use 4 letter codes and all the new software doesn't care what lengths the client IDs are but the vax can only handle 3 character ids.
Heh. Look on the bright side, LS: the EBCDIC dinosaur is at least at
How much of the ASCII table can you fill from memory? 256 points for getting it all right.
Now... how much of the ebcdic table can you fill from memory?
oh, and wrap everything into a mime structure.
(pardon me if I'm still fucking furious at google docs)
more content 1
Look at content 1 and more content 1.
WHAT THE FUCK IS THAT. How the hell do you parse that into anything meaningful?
Referencing opaque binary data via a URI is an interesting approach,
but what do you do when your document absolutely needs to be
self-contained? I ended up using Base 64, but that still seemed like a
less than optimal solution.
There's mime for that. Mime sucks too, but nowhere near as bad as xml for what it's trying to do.
There's one thing (well, maybe more than one thing, but I'll start with one) that I'm not sure I get about WSDL and web services, and this might also apply to CORBA's IDL as well.
What's the real point?
What does a formal XML-based description of your APIs really buy you? If you develop a library, for example, for converting pictures of marshmallows into pictures of toasted marshmallows, you would expect that someone looking for such a service would develop their application towards your API. In other words, they're going to write their application assuming that certain operations, like foo, bar, and baz, are going to be present. Given that, the one advantage I can see to something like WSDL or an IDL is that it tells you what data types are being used, so your application can convert to the proper types, if needed.
To take this a step further, let's say that you're going to provide a service that already has a standardized API. That means the operations your service provides, and the parameters they accept and generate are pretty much already defined. Any application written for that standard API is going to expect those operations to exist, so the service will be written towards that. Another place where something like WSDL could be useful is in cases where portions of the API or API parameters are optional. A WSDL document could then let the application know what features are supported.
Is that what it's all about? Automatic identification and conversion of data types, and the ability to assess a service's feature set? Or is there supposed to be more to WSDL than that?
Feb 21 2011 3:40pm from Ford II @uncnsrd
I'm kinda wondering why google hasn't done this yet. Maybe that was
the plan for google desktop but it never got enough traction to be
Google is (quietly) beta-testing the new Google OS by giving away cloud-based netbooks to qualified testers ....
Anyway, if you control both ends of the link you can just send
whatever tags you want and ignore the need for any formal
specification, but I realize that's a *very* loose and casual way of
Except that nowadays, you probably have to be able to jam your protocol through an http proxy.
Anyway, if you control both ends of the link you can just send whatever tags you want and ignore the need for any formal specification, but I realize that's a *very* loose and casual way of handling things.
When XML first showed up on the scene it was painted as this sort of magic fairy dust that would make every program automatically know how to parse any data format without any work whatsoever!
If I'm reading you right, you're saying that extensibility is one of the prime advantages of WSDL and SOAP. That definitely would be a good advantage.
It's been a while since I've done coding in a compiled language like C, but I definitely do remember the issues involved in changing the contents of a library file that programs depended on. Even if it was just adding new function calls, there was still a risk that the change would break the existing programs.
From what I understand, WSDL is used for specifying web APIs (essentially), whereas a DTD is designed as a validation tool for any XML document.
Were you perhaps thinking about XML schemas, which WSDL uses to describe API messages? If so, I can definitely agree with you. From what I've read, XML schemas definitely have much more flexibility than a DTD, and they can be used in place of a DTD for validation purposes.