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

81–90 of 262 posts

Re: Bring Your Own Client

#81

Post by alanpearce »

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…

remoteStorage[1] is already a thing. I don't think anyone's made a full Word-style document editor for it yet, though.

[1]: https://remotestorage.io

Re: Bring Your Own Client

#82

Post by timw4mail »

deepstack wrote: post #57
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…

>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 with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me. Same can be said about gmail. In the…

Gmail still allows imap access, although it requires an app-specific password. (Or it has to be allowed on the enterprise side with G-Suite)

Re: Bring Your Own Client

#83

Post by kjrose »

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…

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 expected as the whole point is to build a moat around the sales model.

Re: Bring Your Own Client

#84

Post by nimrody »

nickez wrote: post #47
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 just have to do what the phone manufacturers did for the mobile phone connectivity. GSM was a huge hit thanks to interoperability.

It was but then deteriorated into a big patent war with every company trying to shove its proprietary patents into the next cellular standard.

So while everyone can implement the standard, very few can do this profitably (In practice, Qualcomm, Mediatek and to some extent Samsung)

Re: Bring Your Own Client

#85

Post by ChrisMarshallNY »

asim wrote: post #78
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.

Can you elaborate. What kind of API? Just a HTTP/JSON api?

I prefer a REST-like API, like Google uses for their services (basically, sending is done with "raw" GET/POST/PUT arguments, instead of blocks of JSON/XML), and Raw/JSON/XML responses.

But realistically, some levels of functionality are so intense, you need a “beefier” API, like GraphQL.

If that is the case, it might not be a bad idea to review the API. In my opinion, overcomplicated APIs are likely to be the result of the service, trying to exert too much control over the interaction/presentation.

Many times, an API is a "back window" or partial view to a more ambitious effort. For example, if the project is a Web-based framework, it will have a lot of rendering and View/Controller functionality that may be of no interest to something like a specialized text editor for content maintenance, so there would be no reason to expose that functionality.

It may be a good idea to provide a suite of APIs, as opposed to a single one.

Re: Bring Your Own Client

#86

Post by CyberRabbi »

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…

I generally support the spirit of requiring cloud apps to provide equivalently powerful API access to their service. The (solvable) problem is how do you regulate this without stifling development of new cloud apps?

Another more practical problem is how do you even get something like this on the agenda of a lawmaker? This isn’t a readily apparent problem to most people but it likely would result in less monopolistic outcomes for cloud providers and potentially better and/or more efficient products.

Re: Bring Your Own Client

#87

Post by zomglings »

The problem (currently) is that most people simply don't care about being forced to use a particular client - as long as that client looks nice.

I say this with a lot of love for the idea. My company sells a collaborative knowledge base that supports Bringing Your Own Client. Out of the hundreds of users I have spoken to, only ONE has ever asked me if they could use their favorite markdown editor to access their knowledge base.

On the positive side of things, having the capability to bring your own client makes it really easy for us to support many different use cases. We just have to write those clients ourselves.

Re: Bring Your Own Client

#88

Post by 9dev »

Vinnl wrote: post #55
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…

There's been some of that already, not in the sense of governments forcing the separation, but in the sense of governments making the keeping of data a liability, e.g. with the EU's GDPR. There's certainly still a whole class of applications when owning the data is a competitive advantage, but there are also lots of organisation whose core competency is not selling data, even though they do have to work with user dat…

From a European perspective, it depends. I wouldn't ever even consider something like Auth0 to store our user records for example, due to the potential legal fallout of storing all our PII on American servers. You have to be really careful just what kind of storage provider you pick, where their servers are located and which specific regulation your business falls under.

That being said, I'm a huge fan of splitting concerns - such as connecting anything and everything via OAuth delegations with narrowly scoped permissions!

Re: Bring Your Own Client

#89

Post by Cthulhu_ »

zomglings wrote: post #87

The problem (currently) is that most people simply don't care about being forced to use a particular client - as long as that client looks nice. I say this with a lot of love for the idea. My company sells a collaborative knowledge base that supports Bringing Your Own Client. Out of the hundreds of users I have spoken to, only ONE has ever asked me if they could use their favorite markdown editor to access their know…

I think it makes sense to at least have the mindset from a developer's point of view. It helps prevent lock-in between the client and whatever APIs or storage your product uses.

I've tried to build apps with a strict client / server separation for a decade now, it made sense at the time because of mobile apps, and it makes sense now due to application half-life (front-ends don't last as long as their back-ends).

In my current project we may offer API access to our customers in addition to a user interface.

Post reply on HN