ownedthx

... oh :)

In my experience, it wasn't that. Larger companies put value in supporting standards, because it is an important checkbox in their marketing, and SOAP is definitely a standard.

The fact that SOAP is not reasonably supported in a browser was a huge reason it fell down. When SOAP first came on the scene, complicated AJAX based applications were not typical. But as more and more JSON/HTTP APIs emerged in conjunction with browsers becoming more powerful and rich apps build built in them, the meaninglessness & complexity of SOAP grew.

Also, another major issue with SOAP is that most all of the popular tools would generate classes based on a WSDL. This creates a toolchain issue that is readily solved for someone experienced, but can really suck if you are new to the idea of generated code working it's way into your project.

Much worse was the scenario of WSDL versioning in conjunction with these tools that generated classes. If the API never broke backwards compatibility, you should be OK and can just use the newer class representations, counting on the service and tools to deal with null fields appropriately (not always true unfortunately). But if version bumps of an API/WSDL broke backwards compatibility... then you had to have separate class hierarchies for different versions of the WSDL; what an intense headache. Contrast that to web REST APIs; without a formal schema and a lack of class-centric tooling, client libraries would often let the author stuff in the params themselves and let the serializer stuff in the body based on the params; so yes your API is not as formal, but this isn't a big issue but offers infinite flexibility in dealing with one-off versioning issues or interop issues.

As someone else mentioned, some platforms couldn't interop with others (differences as it related to simply stuff like nullable fields or primitives existed all over; total nightmare), and some features of WSDLs didn't translate well to certain languages.

A great WSDL author would know to make their WSDL as simple as possible, because they had spent time working with various language toolchains and new the limitations out there, but that's asking way too much and not realistic for someone to have to spend all their time trying to understand all the ways someone in language XYZ might use their WSDL.

The fallacy here is the assumption that there is value in JavaScript in any form. As a long time web programmer, I can tell you I could care less about the freeness of your Javascript. I don't want to see it, read it, or spend one second trying to understand your smelly bowl of web code.

Fight some other battle, gnu!

Moving to node can be in part a decision to attract fresh talent, as well as keep the current team interested and motivated.

I don't work at an office. I guess you can say I'm on a break.

I work 40 hours a week at a minimum, every week, and have always done so. I'm a programmer primarily, but also do other related things (build, devops, customer support). But if I have a week with nothing but programming, I will still work a minimum of 40 hours a week.

The idea that you can't do more than 15-20 hours a week is not true.

I do love my job. Perhaps that's why I work this much.

I admit that I have a hard time relating to this general idea I see over and over about the need to fill up time with non-work. Also, over the years, I've met my fair share of those who also work just as hard.

JamKazam allows musicians to play with other musicians over the internet in real-time.

There are a number of challenges we've faced so far, but the biggest two are latency and audio gear setup. Latency doesn't only come from the internet; your audio gear and OS can also add quite a bit of delay as well. Our approach with latency is to measure well, and help users reduce latency where they can (and of course optimize our own software to add as little latency as possible).

And we continue to refine how you hook up your audio gear to the JamKazam PC/Mac application. Some gear works great. Some... gives us quite a bit of trouble.

Anyway, the product is usable, although we have much, much more to improve on.

If curious, we are using a RoR w/ Postgresql hosted mostly on Linode. We are using Websockets + RabbitMQ to help route messages between clients and browsers. We communicate over websockets for control messages when initially establishing media between two parties, then ultimately going directly P2P with UDP audio to help with latency; hair-pinning audio through the server is not your best bet.

You can check out some videos...

Musicians jamming: https://www.youtube.com/watch?v=I2reeNKtRjg

Overview: https://www.youtube.com/watch?v=ylYcvTY9CVo

Getting Started: https://www.youtube.com/watch?v=DBo--aj_P1w

Thanks for the reply.

Regarding #2: On OpenIndiana, we first started with concurrent zfs commands and ruin, I think, the whole pool (maybe it wasn't that drastic, but was still a disaster scenario where key data would be lost). I couldn't believe it.

I was asking anyone who knew anything... 'so if two admins were logged in at the same time and made two zvols, they could basically ruin their filesystem'? No one knew for sure. Crazy stuff.

Anyway, I'm quite glad that's safe now.

At a previous job, we built a proof-of-concept Sinatra service (i.e., HTTP/RESTful service) that would, on a certain API call, clone from a specified snapshot, and also create an iscsi target to that new clone. This was on OpenIndiana initially, then some other variant of that OS as a second attempt.

The client making the HTTP request was IPXE; so, every time the machine booted, you'd get yourself a flesh clone + iscsi target and we'd then mount that ISCSI target in IPXE, which would then hand off the ISCSI target to the OS and away you'd go.

The fundamental problem we hit was that there was a linear delay for every new clone; the delay seemed to be 'number of clones * .05 second' or so. This was on extremely fast hardware. It was the ZFS command to clone that was going to slowly.

Around 500 clones, we'd notice these 10/20 second delays. The reason that hurt so bad is that, to our understanding, it wasn't safe to do ZFS commands or ISCSI commands in a parallel manner; the Sinatra service was responsible for serializing all ZFS/ISCSI commands.

So my question to the author:

1) Does this 'delay per clones' ring familiar to you? Does ZFS on Linux have the same issue? It was a killer for us, and I found a thread eventually that implied it would not ever get fixed in Solaris-land.

2) Can you execute concurrent ZFS CLI commands on the OS? Or is that dangerous like we found it to be on Solaris?

Apache Ivy is built on Java and could be a starting point for the uber package manager. It is extremely extensible and can resolve depencies against maven style repos, file systems, and really any other storage mechanism. It can resolve against multiple repos simultaneously.

The real problem is that its so powerful and hard to ramp up on... The docs aren't sufficient for its overall complexity. That all aside, if the will were there, it could be the git of package managers.

We follow a simple rule about technical debt:

If you are working on an issue, and technical debt is affecting your ability to create factored, testable code, then fix the debt.

It might mean a 1 hour issue takes 4 hours, or more. But we put a premium on writing tested code, such that we can push builds often to production.

However, we never make a task ' go fix technical debt X'.

That way, you don't waste time on something that really isn't a problem.

It's working for us well, so far.

That's not a valid generalization.

Yes, if User A, User B, and the server are in a hub city, such as Dallas, then the difference could be small in either direction.

But if user A is in San Francisco, and user B is in San Diego... then routing through the server in Dallas is almost always going to be significantly slower.

So if latency is a concern, and you want to route through your server, you need to now cover the network with servers. That's a big deal.

There is an incentive for real-time audio/video/gaming applications, though: latency.

And many such applications do use P2P.

I have worked on multiple applications that use P2P networking, and the fundamental problem is this:

Not all networks support the ability to P2P network, or, if they do, they require intervention by the user.

So you have two issues: some users will never get to use your application, and for those that could potentially, they will likely need customer support to help them configure their network correctly.

Corporate networks are the worst for this. They aren't going to change their rules for your application (yes, they might, but don't assume that starting out).

A much greater percentage of home networks can support P2P networking, but your application probably needs to support STUN as well as UPNP.

Some number of home routers won't work ever, or can if you configure them correctly. And that's where it gets messy. Is it enough to tell a customer to 'go figure it out', when it pertains to router configuration? You might get away it with PC gamers; but I'd argue any other segment of people will have no idea how to do it, and need some help. So now you have to try figure out the enduser's home router configuration as best you can remotely. Huge drain on customer support resources, which in a small startup, usually means the developers.

So why go P2P with all these headaches? Unless you have a really strong reason to do use P2P, like keeping latency down between peers, you don't bother.

Carl Sjogreen, who leads the platform PM team, commented that good changes are coming:

http://www.sethcall.com/blog/2010/09/30/facebook-api-does-no...

I am really quite pleased he took the time to address the post. Let's hope he can succeed.

You can't count how many ways Facebook wrongs developers.

I had three more sections planned out, but said the heck with it, they've already taken so much of my time.

You are totally right, though.

I tend to agree. I think some better documentation would do go a long way, though.

If you can agree that there is no way to safeguard the application secret key other than keeping it on a server (no matter how u try to bury it in the desktop application, it could be hacked no?), then you have to let your desktop application 'instances' use some sort of API to get their messages signed.

But, you don't want to let anyone just come in and hit this API! That could be expensive, in terms of CPU, bandwidth, and hosting costs. So you want to make sure the desktop application is indeed authorized to do so. So then you need some sort of authentication scheme between your desktop applications and your server... username/passwords being a common such way.

A good summary of OAuth, but as the author, I assure you I do understand this key benefit of OAuth. Admittedly I didn't make a point of it, but there are alot of sites that do a good job of explaining this (as well as your comment).

The issue of the article isn't that. It's when one is actually building a desktop application from scratch. You end up building a web site with a user login... just so you can store the application secret securely!

Note that when I say application secret, I'm not referring to the user's access token & secret that you point out. I agree that storing that info locally on the desktop is fine.

Thanks for replying.

Just the way it worked out. I had taken many screenshots along the way, but at the time I decided to write about my findings, I was in mid-refactor and had nothing that I could run.

In hindsight, I should have used the real deal.

Ah, ok. That's what I was hoping. As a mac user myself, I can confirm that flash.text.engine has excellent, perhaps perfect kerning.

Really? Have you seen it with the new flash.text.engine API? Or just other forms of text in Flash?

As soon as every major browser supports it, count me in :)

(and as soon as a good majority of folks are actually using those browser versions!)

Gah. Again, as I posted up above, text selection is possible. going to update the post to indicate that...

Actually that's no problem...

The SWF in the article were two snapshots that I overlayed, one from Flash, one from Word, so it has no interactivity with the curser.

Truth is, it's entirely possible to enable text selection, if that were a real demo of the text engine.

Actually, in some adhoc tests, it's control over character spacing is pretty bad. Firefox 3 has the best control--you can tweak character spacing at the sub-pixel level, but not for Safari or IE. Firefox also has very good default character spacing, whereas IE and Safari's was a little bit off of what it should be.

The reason is simple: REST forbids a server being aware of client state. So practically, this means sessions are off limits; cookies for managing sessions are meaningless in such a world.

To send an event to a client, though, means the server must have some sort of awareness of the client. Otherwise, it wouldn't know to send the client a message in the first place.

So, can you have events in conjunction with REST? Sure. Just realize once you do that, your application isn't 100% RESTful. It's RESTful and... RESTless I guess :)

I totally agree... the issue is that some people don't realize that it's not the answer to all problems, and chaos ensues...