Hacker News Reader

Comment by mixedbit | Hacker News Reader

This is the reason why proprietary cloud services will never be as flexible as traditional programs on our computers. With N cloud services there need to be N^2 integrations to make them all work together. With N desktop programs it is enough if each of them implements a single common API (for example text bast stdin/stdout Posix API) to make them all work together.

Imagine if 'cat' and 'sort' needed to implement a dedicated API to work together, and then 'sed' would add another one, and 'wc' another. This is a kind of mess that we see with cloud services integrations.

View on HN

In the Windows world, OLE and COM did things that you can only dream of in the Cloud world.

OLE[0] allowed one application to embed content from another application, without needing to know anything about the other application. It even had facilities to sort-of merge the UIs, so if you were editing a CorelDRAW drawing within your Excel spreadsheet you'd get a subset of the CorelDRAW toolbars and menus within your Excel window. All of this was done at runtime - there was no special programming in Excel to embed a CorelDRAW object.

This stuff actually worked and worked surprisingly well. It's unfortunate that we seem to have lost this.

I don't think we'll ever see this happen to the same extent. The only integrations will be ones that are specifically approved and developed, all N^2 of them.

[0] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding

OLE was and is brilliant. As a kid I always loved watching it contort to embed something ridiculous like Paint Shop Pro into Microsoft Word

I hope DDE/OLE/COM+ and later DCOM could evolve to a next level:

cross-computer embedding.

e.g. During a conference, drag drop a certain part of UI from a remote computer for real-time demonstration.

Even embed a content into an email and send it to a friend, as long as your computer stays on your friend can open part of your widget.

This was the promise of Lotus Notes. Sadly, the implementation and especially the UI dragged it down.

This is what we're working on at Horbito. The Internet is clearly broken, it wasn't designed for this cases and now the are big players trying to monopolize with their suites. We've created a campaign explaining this problem to sensitize the users: https://www.theinternetisbroken.io

Why couldn't cloud providers adopt a common API? Some providers are adopting AWS apis for their services.

And we can also look at the email example : a lot of cloud provide email services and they all use the same protocols (SMTP, IMAP...).

Because they want to lock their customers to their platform. AWS has the biggest marketshare, so if a smaller provider adopts AWS's api, that means that AWS customers can easily migrate to them.

I do wonder how we managed to get standard protocols adopted for email. What did email providers use before SMTP and IMAP? Maybe the key difference then from now was that the internet community was much smaller? Did Mark Crispin simply write the RFC for IMAP, email vendors noticed on their own, and adopted the protocol? Or was the emailing community then so small that there were no vendors and it was really just a handful of programmers, who could discuss and agree on protocols via something like Usenet and implement their own clients and servers?

more the latter. long ago, to get access to mail or usenet you generally were a technically minded person at one of a few universities or large corporations like DEC. to give a sense of the scale involved, check out http://olduse.net/blog/current_usenet_map/ . There were on the order of between dozens and hundreds of machines, and you would send mail to a person on a given machine by figuring out (by hand?) a path from your machine to that machine and include the names of all the machines in a "bang path" http://www.catb.org/jargon/html/B/bang-path.html

Also, before SMTP there was UUCP (which was used for both mail and usenet).

I agree with the profit/control motivations the other posters mention, but there are other less anti-users reason as well.

Agreeing on a common API mostly locks you into the common denominator of features. It becomes much harder to ship new capabilities to your customers if you also have to add those features to this standardized interface and get all the stakeholders to move forward with it. All these platforms have some features that their competitors lack and it'd be quite the challenge to expose each platform's unique features in a standardized API.

Email (IMAP/SMTP) is a success story of a widely adopted standard, but it's also something that has barely changed in the last 15-20 years partially as a result of its standardization. You can tell IMAP is cumbersome to the modern developer. For example, you'll have an easier time working with a gmail account by using the gmail REST API instead of trying to use IMAP. (IMAP has more limited search support, lower-level thread support, and less specific support for syncing clients)

They probably could, but it isn't happening. It is hard to find a cloud service that seamlessly works with some other cloud service without explicit integration between the two services.

Email was introduced and has become a popular standard long before commercial cloud services. The companies adopted it, but they do not seem to be interested in introducing similar standard protocols for new APIs.

Exactly right that the proprietary nature of Google and Dropbox are the problem.

Proprietary software suffers from a fundamental flaw that limits its usefulness as a technology. It's a technical problem.

We created a unified cloud storage API at https://kloudless.com to help solve this integration problem.

Imho, this is a problem that shouldn't be solved by single companies in isolation. Otherwise, we end up with 15 different standards.

Agreed! Making all your API calls to Kloudless (or cloud elements, cloudrail, etc...) instead of individual services is certainly nicer for the developer, but creates another for-profit entity that's just in the middle of it all.

To really be like email we'd be talking about a common protocol that all the service providers implement so software can speak to all providers directly in the same way without a middleman. (A better WebDAV with industry support?)

Well, there have been attempts to create single standards (e.g. CMIS, in the content management space). A lot of the time, enabling the right workflow for the integration to be useful involves providing capabilities that quickly diverge from any common standard that is agreed on. Tying together different business stacks involves a lot more than just establishing API endpoints for individual actions.

Having a single API reduces this inevitable maintenance overhead and swaps out some set of N integrations in favor of one other. There is the added benefit of having a resource (Kloudless, in this case) assist with enabling whichever use case the business is trying to solve for their users by providing the integrations.

Which is better than 15^2 different standards.

https://xkcd.com/927/

"How standards proliferate" :D

I think the real problem is that cloud services relieved some of the pressure to invent standard file formats. And then greedy companies wanted to be walled gardens, rather than integrating with each other.

But when propriety cloud services WANT to work together, they need to come up with standard file (or stream) formats. When they do, integration is often not that hard.

That argument only holds when cloud services do not adopt a common API between each other. (The GDPR might change it since it demands data portability in a common format)

(And posix stdin/out is quite terrible tbh, imagine if cat and sort could emit structured objects like in powershell)

Reply on news.ycombinator.com