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

11–20 of 262 posts

Re: Bring Your Own Client

#11

Post by stupidcar »

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 with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me.

This wouldn't be a panacea, but it at least makes it theoretically possible to write a replacement client for Google Docs that could be a drop-in replacement.

Re: Bring Your Own Client

#13

Post by okl »

tobr wrote: post #6
madeofpalk wrote: post #4

Git does not have colaboration tools. It's very much a "work in a silo for a period of time and then evtually figure out how to mash these things together" approach.

Has anyone tried to build real-time collaboration on git? What if every participant would run a system that saved on every keystroke, committed and synced with the remote? It would break due to conflicts as soon as two concurrent edits were too close to each other, but you could probably just accept either commit when they’re so granular and happening in real time. The conflict is going to be obvious and fairly easy…

Keep in mind that a big part of working with a VCS is refining your code until it is done or ready to be merged. Syncing on every keystroke would drown others in noise and I'm usually not interested to see my colleagues' unpolished work-in-progress code.

Re: Bring Your Own Client

#14

Post by asim »

We had standardisation at the protocol level for the internet which let us build services on top, but now we're looking for the same at the app level. HTTP was meant for web pages, we never created anything for Apps and Services. What that new standard is going to look like, I have no idea, gRPC does well to define the APIs and so we use it across dozens of services here https://github.com/micro/services. Curious to hear what others think will happen.

Re: Bring Your Own Client

#15

Post by EuAndreh »

madeofpalk wrote: post #4

Git does not have colaboration tools. It's very much a "work in a silo for a period of time and then evtually figure out how to mash these things together" approach.

That is false. See the built-in git-send-email [0] and git-am [1] commands.

You may not like it, don't use it, etc. But Git does have collaboration tools.

[0]: https://git-scm.com/docs/git-send-email

[1]: https://git-scm.com/docs/git-am

Re: Bring Your Own Client

#16

Post by bombcar »

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

And this works both ways. Like the Postgres standard API you mention: Not only does it allow you to bring your own client, you can swap the underlying implementation and still use all the clients that speak the protocol. Like the author I would really like to see some open protocols (and adoption) for todo's and calendars. I mention adoption because for calendars there are some standards but popular software like Goo…

Calendaring is a huge embarrassment and a mess, and it is super annoying if you have to deal with anyone “outside” your group. Emailed ical files seems to be the norm but only work over email. :(

Re: Bring Your Own Client

#17

Post by o_m »

I feel Reddit is another thing that has "Bring your own client". I'm using the old design and Reddit Enhancement Suite to tweak it to whatever I want. Reddit also gives you everything as JSON if you just add ".json" behind any URL.

Re: Bring Your Own Client

#18

Post by pjc50 »

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…

Interesting proposal, but I see it greatly reducing development and also further entrenching the cloud providers as Lords Of Everything.

Re: Bring Your Own Client

#19

Post by pjc50 »

tobr wrote: post #6
madeofpalk wrote: post #4

Git does not have colaboration tools. It's very much a "work in a silo for a period of time and then evtually figure out how to mash these things together" approach.

Has anyone tried to build real-time collaboration on git? What if every participant would run a system that saved on every keystroke, committed and synced with the remote? It would break due to conflicts as soon as two concurrent edits were too close to each other, but you could probably just accept either commit when they’re so granular and happening in real time. The conflict is going to be obvious and fairly easy…

... why would you want that? How would you ever run the program when it's broken on every keystroke?

Re: Bring Your Own Client

#20

Post by eric4smith »

The main reason for using google docs is not it’s superlative editor... /sarcasm

It’s the collaboration features. And no I don’t mean the multiple people typing the doc at the same time.

It’s the ability to quickly share a document with a set of people that you want.

Sure I use Vim every day, but without that git push and a trip to GitHub to invite collaborators I’m a man on a desert island waiting for that next weekly ferry.

Code editors and that ecosystem is good for code, but too slow for people who just want to share some recipes with their brother and not think about it too much.

Until we have some sharing infrastructure easy enough for a any client to sit on top of, it’s all a dream.

Post reply on HN