Live data from Hacker News

Bring Your Own Client

geoffreylitt.com

141–150 of 262 posts

Re: Bring Your Own Client

#141
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…

One of the better examples still seeing widespread mainstream use is email, and this even applies to multiple stages throughout the email ecosystem: sending mail, receiving mail, managing mailboxes. Imagine if email wasn't cross provider compatible

Email is only useful because it is cross platform compatible. Otherwise, we’d all be back to writing to some friends in AOL, others in MSN, maybe some back in Compuserve. Some people like to send messages only in Facebook and others via Twitter DMs. None of these are/were interoperable which is why they aren’t ubiquitously used.

Email is only useful because each server can send and receive with other servers.

But we all know this, so what the point here?

I would say that my point is that if interoperability becomes more useful than the walled garden approach, then we will see something like this posts call for BYO client. Email is an example. We have interoperable email because it is was more useful than service specific inboxes.

Until interoperability is necessary for Word, we won’t see an opening for other Word “clients”.

Aside: you could argue that Google built Gmail to make a dent in the ubiquity that was Exchange for corporate messaging. It exploited the openness/interoperability of email in order to do this. If you accept that argument, then maybe they should take a page from that playbook and work to make Google Docs as open as possible. Allow for more interaction with external clients. Let a more open ecosystem develop. That might have the potential to diminish the position of Office for document creation.

Or maybe email is just so old, the owners got established before it could be commercialized... it might happen again, but I’m not hopeful. For example, I don’t expect Twitter to care about federating their system with other messaging applications. There is too much to be gained (selling ads) by keeping people on their site.

Re: Bring Your Own Client

#142
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…

One of the better examples still seeing widespread mainstream use is email, and this even applies to multiple stages throughout the email ecosystem: sending mail, receiving mail, managing mailboxes. Imagine if email wasn't cross provider compatible

Absolutely, however a major problem occurs, and email is a great example of this. When there is a fundamental need to change the protocol for reasons of privacy, security, authentication, etc. It becomes almost impossible to do when it is as wide spread as email, or it takes a very very long time to spread enough.

When one person controls the whole system, it's easy to pivot rapidly. I guess that's another argument against having widely used protocols (even though I disagree with it.)

Re: Bring Your Own Client

#143
post #137

Re: Notion, Trello, etc. — wouldn’t enabling interoperability on top of a presumably-free “open core”, completely commoditize these services? (As, for anything they offered on top of their open core, you could instead substitute a third-party service that does the same thing by operating against the service’s API.) Which is to say — in a world where interoperability is a social norm or legal requirement, how would th…

[deleted]

Re: Bring Your Own Client

#144

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 think it's not completely inconceivable that this could be regulated some day with music streaming. There are zero technical hurdles (unlike with complex apps like Google docs), and because there is such potential for decoupling the client the consumer benefits would likely be much greater.

I've been meaning to switch from Apple Music to Spotify for a while now (I'm on Android). I just had a look around the Spotify app today and the interface is terrible, it won't let me play and view my library like I want to. It would be so much easier if I could just use both from a single open source client, and then I wouldn't have to switch off to soundcloud and bandcamp for certain artists.

Wouldn't it be in the interests of players like Google and Apple to create this service/protocol, even before the regulatory net starts closing in?

Re: Bring Your Own Client

#145
post #138

Unirest is the BYOC that I was hoping would get traction: https://github.com/kong?q=unirest I don't understand why each API needs it's own SDK. Or even why developers use SDKs instead of just calling the RESTful endpoints directly.

I understand both sides of it. The thing is that most code bases that aren't using an official SDK will tend to wrap the raw HTTP calls in something that performs the relevant operations anyway. A good SDK cuts out a few classes/functions that would have been written anyway.

Of course, that assumes that the SDK exists and is good.

Re: Bring Your Own Client

#146
post #98
post #90

Background gradient makes me dizzy after reading a single paragraph

(author here) sorry to hear that! Out of curiosity, what screen size are you reading on? Anyone else have similar problems? Sounds like I should add a button to disable the gradient.

It's a cool idea but I wrote a userstyle to override it. Reading on a plain color is easier for me

Re: Bring Your Own Client

#147
post #138

Unirest is the BYOC that I was hoping would get traction: https://github.com/kong?q=unirest I don't understand why each API needs it's own SDK. Or even why developers use SDKs instead of just calling the RESTful endpoints directly.

If the SDK in question is just a thin wrapper on REST then sure, it isn't providing very much value. But most of the SDKs I've used implement higher level logical operations -- things that require understanding the intent of the API/data model and how things are supposed to fit together. By being able to write my code against that higher level abstraction I'm able to save time and offload some of the responsibility for knowing how the pieces all fit together to the people who know that best. Ultimately my goal is not to make REST requests, it's to provide value to my customers, and the APIs I call are means to that end.

Re: Bring Your Own Client

#148
post #137

Re: Notion, Trello, etc. — wouldn’t enabling interoperability on top of a presumably-free “open core”, completely commoditize these services? (As, for anything they offered on top of their open core, you could instead substitute a third-party service that does the same thing by operating against the service’s API.) Which is to say — in a world where interoperability is a social norm or legal requirement, how would th…

> in a world where interoperability is a social norm or legal requirement, how would these services exist? (I would suspect they wouldn’t.) And, without them, would there be any money in advancing the state of the art in these verticals?

They would. The verticals wouldn't. A service like Trello is at least two components - a storage layer for lightly connected lists of rich data, and UI for displaying/managing them. In a world where interoperability would be the norm, these two components would be two different markets. The user would be free to choose or buy the UI separately from the storage layer. Most would probably choose a vendor that provides both services, just out of convenience.

The main difference would be that all these companies would operate on lower margins, and wouldn't support such insane valuations like our-world tech companies have these days.

Re: Bring Your Own Client

#149
I think no one wants to go through the work of creating a full featured client. What most people want is just adhoc customizability.

For this reason, the web is great if you know how to code. Most sites are pretty easy to reverse-engineer so you can add whatever feature you want via extensions.

For example I do a lot of simple stuff with greasemonkey scripts like making stuff sortable or filterable, creating a bulk download and rename button, or just customizing appearances/css.

Post reply on HN