4 ms·

>An unsolved problem is how to program a webbrowser in less than 20 KLOC. How about instead of a full web runtime you change the problem to be implementing (or

>An unsolved problem is how to program a webbrowser in less than 20 KLOC. How about instead of a full web runtime you change the problem to be implementing (or inventing) server and client protocols for common web services? (Vblogging, Q&A forums, micro blogging, social bookmarking, wiki's etc.)

mikedelfino 2y ago
This is something I often think about — if I understood you correctly. It sounds like an evolution of Gopher, with predefined structures for navigation, documents, and media. When we browse, we care more about the content than the presentation. There’s no real need for different layouts for blogs, documentation, news, forums, CRUD apps, streamings, emails, shops, banking, and so on. If the scope were tightly restricted, implementing clients and servers would be much simpler. But it's just something I wonder about...
- bobajeff 2y ago
  Yeah, that's right. Though, it needs not be just one protocol. Many sites already have clients. It's just that the APIs are typically controlled by the site and are not client neutral and require credentials as opposed to something like an RSS feed.
beagle3 2y ago
The reason the web won is that it does NOT need specific clients for every single thing. Essentially every kind of service (e.g. email, blogging, q&a, live news) is available without JavaScript, thus, using a pure html through http interface. The problem with a-standard-protocol-per-service is that new uses arrive in a distributed, unplanned manner. Looking at instant messaging history is instructive: there were 3 protocols in major use (aim, msn, icq) about 20 other in common use. The “standard” committee was sabotaged by the major players for years and eventually disbanded, culminating in the only open option in some use (not major use, just some use) - XMPP - to win by default, except the providers explicitly chose to NOT interop (Facebook, WhatsApp when it was independent, Google chat).
- bobajeff 2y ago
  People still use clients for certain services otherwise many sites wouldn't still be making them. Of course you're right that this would all be hardcoded and would not allow new types of sites to work right away. I don't know that you'd even need a protocol or service for each category of site. It would probably make more sense to use the same architecture for all types of services with something like a manifest to determine the mode. I think the challenge would be making the APIs public in a way that would be practical for the servers implementing them.
  - beagle3 2y ago
    There is one such client architecture. It’s called the web. You are describing the present state.
    - bobajeff 2y ago
      I think you misunderstood me. I'm not at all describing anything like a application runtime such as the web. By architecture I meant something more like server APIs that are flexible enough to be used as the backend in different kinds of sites. For example: Instead of an API for microblogs and another for blogs and another for news sites it could just be one API with flags or something that determines which other calls are used and how.
      - beagle3 2y ago
        So let’s say we have blogger with a blogger API, and twitter with a Twitter API, and by some miracle they agree on a merged-with-flags API. Along comes Tumblr, and … the APIs don’t fit, in the sense that they significantly limit the planned functionality. Now what? A new API! Or a committee to update the existing API! Central planning doesn’t work for these things. And when you do finally have agreement on something (e.g. email), you either stagnate because no one can improve things, or get incompatible implementations because a significant player decides they will break the standard for some reason (e.g. recall and TNEF on outlook, which only work on outlook). The internet started the way you describe (with finger .plan for “social” status, Unix talk for one-to-one, IRC for chat, email, nntp, gopher, ftp, Xwindows, RDP, etc etc). All of these is are 98% web based these days, because the protocol+client+server model cannot adapt quickly enough. The modern web with presentation layer + runtime code delivery + transport protocol does allow lightning fast evolution.

mikedelfino 2y ago

This is something I often think about — if I understood you correctly. It sounds like an evolution of Gopher, with predefined structures for navigation, documents, and media. When we browse, we care more about the content than the presentation. There’s no real need for different layouts for blogs, documentation, news, forums, CRUD apps, streamings, emails, shops, banking, and so on. If the scope were tightly restricted, implementing clients and servers would be much simpler. But it's just something I wonder about...

bobajeff 2y ago
Yeah, that's right. Though, it needs not be just one protocol. Many sites already have clients. It's just that the APIs are typically controlled by the site and are not client neutral and require credentials as opposed to something like an RSS feed.

beagle3 2y ago

The reason the web won is that it does NOT need specific clients for every single thing. Essentially every kind of service (e.g. email, blogging, q&a, live news) is available without JavaScript, thus, using a pure html through http interface. The problem with a-standard-protocol-per-service is that new uses arrive in a distributed, unplanned manner. Looking at instant messaging history is instructive: there were 3 protocols in major use (aim, msn, icq) about 20 other in common use. The “standard” committee was sabotaged by the major players for years and eventually disbanded, culminating in the only open option in some use (not major use, just some use) - XMPP - to win by default, except the providers explicitly chose to NOT interop (Facebook, WhatsApp when it was independent, Google chat).

bobajeff 2y ago
People still use clients for certain services otherwise many sites wouldn't still be making them. Of course you're right that this would all be hardcoded and would not allow new types of sites to work right away. I don't know that you'd even need a protocol or service for each category of site. It would probably make more sense to use the same architecture for all types of services with something like a manifest to determine the mode. I think the challenge would be making the APIs public in a way that would be practical for the servers implementing them.
- beagle3 2y ago
  There is one such client architecture. It’s called the web. You are describing the present state.
  - bobajeff 2y ago
    I think you misunderstood me. I'm not at all describing anything like a application runtime such as the web. By architecture I meant something more like server APIs that are flexible enough to be used as the backend in different kinds of sites. For example: Instead of an API for microblogs and another for blogs and another for news sites it could just be one API with flags or something that determines which other calls are used and how.
    - beagle3 2y ago
      So let’s say we have blogger with a blogger API, and twitter with a Twitter API, and by some miracle they agree on a merged-with-flags API. Along comes Tumblr, and … the APIs don’t fit, in the sense that they significantly limit the planned functionality. Now what? A new API! Or a committee to update the existing API! Central planning doesn’t work for these things. And when you do finally have agreement on something (e.g. email), you either stagnate because no one can improve things, or get incompatible implementations because a significant player decides they will break the standard for some reason (e.g. recall and TNEF on outlook, which only work on outlook). The internet started the way you describe (with finger .plan for “social” status, Unix talk for one-to-one, IRC for chat, email, nntp, gopher, ftp, Xwindows, RDP, etc etc). All of these is are 98% web based these days, because the protocol+client+server model cannot adapt quickly enough. The modern web with presentation layer + runtime code delivery + transport protocol does allow lightning fast evolution.