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.
hm, thats html, not xml. I don't think its legal in xml.
I can see it's advantages over HTML, and there are a number of places where XML is definitely a better choice than some alternatives, but, like everything else, it's just one of many tools. If it's not the right tool, then I won't use it.
For example, I was considering using XML for a project here at work to describe details of the various hardware platforms we have to test. However, after some thinking about how this information will be generated and used, I'm leaning more towards a domain-specific language (DSL) for the task. I don't know yet if I can find an existing language that meets our needs (that would be great) or if I'll have to develop one. However, I don't think XML will be the right choice; the users who will have to generate the data may not be very familiar with XML, though there is a structure to the data, it's not as clear-cut as XML would like it to be (nor would it fit very well in relational database, maybe an object database, but the datasaet is way too small to require a DBMS), and it would be a lot of effort to develop a custom tool with a nice front-end UI so the users wouldn't have to muck with the XML.
Despite that, though, I'm still with Ford and bart in that any large chunk of opaque binary data should be kept well away from XML. Make a tag that lets you reference that object via a URI instead of trying to include it in the document. Then it becomes the application's job to fetch it instead of the parser, and the application can more likely than not make smarter decisions about what to do.
spell, I was just a little trolling.
WSDLs are just sort of CORBA-IDL expressed in XML. and, of course WSDL is just a bunch of DTDs.
btw, I like what you can do with SOAP-UI.