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

251–260 of 262 posts

Re: Bring Your Own Client

#251

Post by lupire »

IX-103 wrote: post #194
mindslight wrote: post #192

Earlier quoted context omitted.

We can split the difference by mandating that whatever storage services are provided via "webapps" must also be provided via a plain API. Users shouldn't have their data locked behind proprietary javascript. This would create zero additional burden, as every webapp needs such an API for the front end to talk to anyway.

Maintaining a stable API surface is a burden. That said, I would agree with such a mandate, as the costs are probably worth it.

Stable isn't required. Just let the users use the same API the client software (JS,mobile) uses, with password or key authentication. Free market will build clients.

For security against social engineering, add some rigamarole around opting into API access.

Re: Bring Your Own Client

#252

Post by lupire »

mbreese wrote: post #141
ivan888 wrote: post #130

Earlier quoted context omitted.

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…

Gmail was Embrace, Extend, Extinguish. You can't read your own email using you own email client anymore.

Re: Bring Your Own Client

#253

Post by lupire »

kjrose wrote: post #142
ivan888 wrote: post #130

Earlier quoted context omitted.

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 a…

What's insecure or frozen about email? We have SPF and all that jazz.

Re: Bring Your Own Client

#254

Post by lupire »

nvrspyx wrote: post #170
Lammy wrote: post #163

Earlier quoted context omitted.

This view is the one that feels shoehorned. "Normies" (not pejorative) have no idea what a protocol is. They just want something that works and is convenient as possible. That's how we ended up at the $free+$surveillance App Store / modern Web model.

Since when was HN a normie site?

HN builds products for "normies".

Re: Bring Your Own Client

#255

Post by lupire »

nvrspyx wrote: post #127
api wrote: post #97

Earlier quoted context omitted.

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.

That view seems a little shoehorned because the parent comment specified "protocol", implying that it would be the connection between client and storage, thus not user-facing. Regardless, * Blender * Godot * Krita * GitLab * Olive * Firefox * Thunderbird * NextCloud * Amarok * Vital * and more The problem isn't an "economic model". The problem is that most open-source projects simply don't attract UI designers, UX re…

Volunteerism is much rarer than paid work, and paid work prefers proprietary too get the money to pay.

And volunteerism was much more popular in the 1990s when it was easy to write software by hard to sell it. App stores suffocated open source by offering a path to revenue.

Re: Bring Your Own Client

#257

Post by wittyreference »

phren0logy wrote: post #110
wittyreference wrote: post #104

Earlier quoted context omitted.

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.

The problem, from my perspective, is that we're fighting the battle on two fronts: I need to get all my data from my old EMR into my new EMR, and I need my new EMR to slot in where my old EMR was with respect to feeding data to my data warehouse. Part of the difficulty there is the API, and part of it is that a bunch of shit is done as a black box in-EMR (e.g., my EMR will feed my warehouse some financial data, but my vendor is opaque as to how it's calculated).

It's gotten to the point where I don't want a legal requirement to be HLX compatible: I want a legal requirement separating back-end data from front-end UI, so that we can shop for each of those independently. Once all the front-end shops (which are more valuable than back-end - as a healthcare org, I care about documentation and billing and error prevention) can't lock you in via data, I imagine there will be a fucking quick race to be the universally compatible back-end. And the back-end is ultimately the stuff that affects patients (portability of records) and loosen the bindings on provider organizations (because... portability of records).

Which of course is why even things like HLX didn't really start working until major orgs like CMS and NYS Medicaid came along and said "you will find a way to be compatible with HLX voluntarily, or you will do it via regulation. One way or another it's going to happen within the next 12 months." (I was at a major conference where that was laid out pretty much that explicitly. It was wonderful.)

Re: Bring Your Own Client

#258

Post by MichaelApproved »

polote wrote: post #199
MichaelApproved wrote: post #181

Earlier quoted context omitted.

First, that’s not the full spec for Google docs. It’s missing many aspects of the environment. Second, is that meant for building a full blown client or is it meant for 3rd party integrations, like plugins?

> It’s missing many aspects of the environment. I'm curious of what is missing > Second, is that meant for building a full blown client or is it meant for 3rd party integrations, like plugins? It is certainly not for plugins, as there libraries to call that API from python, ruby and others which are then not meant to be run in the browser. My point, is that if you want to build an editor of Google Docs, then you can…

> I'm curious of what is missing

My initial response was related to missing comments and collaborative real-time editing in the v1 link you provided. However, I searched a bit more and found that their newer API versions include both of those features.[1]

Here's a blog that's announcing their real-time collaborative editing[2] back in 2013, so that's been there for a while.

That blog post also lists a few products that make use of the real-time feature but the only client that's an actual editor ("Neutron Drive") has since died with its domains no longer working.

I guess this is one of the rare cases where you can build a client based on their API and Google actually promoted one of them but I'd still say that it's not really meant for it.

The primary use case for these APIs are bot services like Zapier and integrating a "Save to cloud folder" feature in your own app.

Even if they actively encouraged you to build a client based on their API, who would risk it? We've seen how Twitter handled 3rd party clients after it got big and that's likely going to be the case with every major player.

[1] https://developers.google.com/drive/api/v3/manage-comments

[2] https://developers.googleblog.com/2013/03/build-collaborativ...

Re: Bring Your Own Client

#259

Post by folex »

gklitt wrote: post #98
folex wrote: 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.

Hi! Sorry for the late reply.

Here's a screenshot of my screen from the time of writing the comment https://i.imgur.com/ngD1Xkj.png

I'm on a macbook pro 15.4-inch (2880 x 1800).

I see you've changed background, thank you for that! .

(though f.lux is on Movie Mode, meaning the dim and color correction are lighter than default)

P.S. I do not know of and never experienced any color perception problems.

Re: Bring Your Own Client

#260

Post by yencabulator »

okl wrote: post #8
bombcar wrote: post #2

This strikes at something that people often WANT when they say "text files are better than the registry/binary formats" - they want to easily bring their own tooling to bear. Standard APIs let you do this - even if you have a "binary format" like MySQL or PostgreSQL (on disk) - nobody really complains about that because they have a defined API you can interact with.

Or SQLite, which I would recommend over some homebrewed text file format, see https://www.sqlite.org/appfileformat.html

Opening untrusted SQLite files tends to not be safe: https://research.checkpoint.com/select-code_execution-from-u...
Post reply on HN