Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bring Your Own Client

geoffreylitt.com

Post reply on HN
Print view View original

101–110 of 262 posts

Re: Bring Your Own Client

#101

Post by kgwxd »

ChrisMarshallNY wrote: post #74

Really, a good API is all that is necessary. Also, maybe an SDK, but I am not particularly enthused by some of the SDKs I encounter, these days. If a service can be exposed by a good, basic API that doesn't require (but also affords) an SDK, then this allows development of connectors. Many client packages, these days, are written to allow connectors to be developed.

For data-only applications. But if an application wants or needs to promise pixel-perfect results, at the very least, there would need to be a single standard rendering engine.

Re: Bring Your Own Client

#102

Post by phren0logy »

I'm in medicine, and I desperately want this model for electronic health records.

The current state of lock-in has been effectively maintained by the entrenched players, and it's really bad.

Re: Bring Your Own Client

#103

Post by indymike »

Most of these closed systems exist because of gaps in the open alternatives, and those gaps may be be difficult to close. For example, an open client for Google docs, which works fundamentally differently than say, a closed-source word processor that was written in the 90s.

Re: Bring Your Own Client

#104

Post by wittyreference »

phren0logy wrote: post #102

I'm in medicine, and I desperately want this model for electronic health records. The current state of lock-in has been effectively maintained by the entrenched players, and it's really bad.

Since HLX has become increasingly required, I've seen that the lock-in doesn't mean diddly squat. Now we're not "locked in", but for my new vendor to drop-in means I have to pay an extra "API Fee" for them to whip up the API interface to pull everything from the old EMR and into the new EMR.

So either we get to the point where we are legislating perfect compatibility (and I can't imagine how good EMRs will get once the federal government has to outline every individual data field, and update them through, what, the rulemaking process?); or we'll always be paying up for this transition, and lock-in is beside the point.

Re: Bring Your Own Client

#105

Post by edoceo »

api wrote: post #97
kjrose wrote: post #83

Earlier quoted context omitted.

Well it can happen if a significant enough open source project establishes a protocol early enough and doesn't get co-opted. That or a consortium of companies agree on some sort of standard. (See the work on pc buses in the early pc days) But you are right. When companies run under trying to get as many users locked in as possible during a paid for investors period. This model is precisely the opposite outcome expect…

For something to get traction, it has to have excellent UI and UX. So far open source hasn't been very successful at providing that since there is no economic model to finance the immense amount of work required for good UX.

GitLab? Xfce?

Re: Bring Your Own Client

#106

Post by greenie_beans »

I would like something like this but for banking logs. I got an alert from the bank about suspicious activity yesterday. The customer support rep couldn’t give me much information about it. I had to stop myself from asking if I could see the logs to determine myself whether it was a bug in their code or a real risk... I wondered if it was a bug because they had a similar buggy incident in the past.

Re: Bring Your Own Client

#107

Post by finiteseries »

throwaway316943 wrote: post #36
stupidcar wrote: post #11

The competitive advantages of owning both the application and the data are so high that don't see widespread BYOC ever happening without government intervention. I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate wi…

We need NPT for software https://en.m.wikipedia.org/wiki/National_pipe_thread

I genuinely cannot tell you how relieved I am this isn’t a link to the Treaty on the Non-Proliferation of Nuclear Weapons, the thought of FAANG cos “disarming” but snuffing out competitors with government approval is terrifying.

https://datatransferproject.dev/ from yesterday’s iCloud photos thread seems to be a step in this NPT direction though.

Re: Bring Your Own Client

#108

Post by stupidcar »

pjc50 wrote: post #79
stupidcar wrote: post #42

Earlier quoted context omitted.

Can I ask why? As I see it, cloud providers are currently entrenched as Lords of Everything because they can both provide the infrastructure and the products that run on top of it. Making them act more like utility providers would reduce their power, I think.

Think it through: > enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate with a separate storage provider. Now, is the law going to mandate the exact API as well? The likely implementation of this is that, just as every app developer co…

Your objections seem to be predicated on the assumption that the attempt to separate storage providers from application providers wouldn't be properly enforced. Yes, obviously if Alphabet can just set up Google Cloud Storage and Google Cloud Apps and continue with business as usual, then this won't work.

But what I'm suggesting would be a functioning regulatory regime: An independent authority who classifies cloud providers as utilities, writes regulations specifying standards of interoperability, hears complaints from people and businesses and acts to enforce them. Antitrust regulation that stops collusion between service and application providers, and prevents companies or individuals owning a controlling stake in both.

And the major difference I see in contrast to railways is digital infrastructure is not limited in they same way physical infrastructure is. So long as there's only one set of tracks, you can never have a functioning market running trains on them, and it's impossible to build a second set. But while the capital costs of setting up a new data centre are large, they are still within the realm of possibility for many large companies.

Re: Bring Your Own Client

#109

Post by luplex »

tantalor wrote: post #73
luplex wrote: post #30

It's a situation like parents: There should be an incentive for a company to build a closed, innovative system. But once that system converges on features, and they reaped their rewards, it should be replaced by an open standard. Instant messaging was fine, WhatsApp and Slack brought a lot of innovation and drove adoption, and I would argue it has gotten to a stable place where we should all use Matrix. We need to fi…

> situation like parents patents?

yes. patents :)

Re: Bring Your Own Client

#110

Post by phren0logy »

wittyreference wrote: post #104
phren0logy wrote: post #102

I'm in medicine, and I desperately want this model for electronic health records. The current state of lock-in has been effectively maintained by the entrenched players, and it's really bad.

Since HLX has become increasingly required, I've seen that the lock-in doesn't mean diddly squat. Now we're not "locked in", but for my new vendor to drop-in means I have to pay an extra "API Fee" for them to whip up the API interface to pull everything from the old EMR and into the new EMR. So either we get to the point where we are legislating perfect compatibility (and I can't imagine how good EMRs will get once t…

Maybe we need a coalition of second-tier EMRs to band together and commit to supporting an API and a group to keep it open and updated? I agree that the current approach isn't really working, and doing more of the same is probably not going to help.
Post reply on HN