4 ms·

Terrible idea. Why would anyone want to deal with interfacing a bunch of randomly structured databases whose tables can change at any time without warning. Nigh

by togaen 5y ago

Terrible idea. Why would anyone want to deal with interfacing a bunch of randomly structured databases whose tables can change at any time without warning. Nightmare.

scotty79 5y ago
Not when compared to alternative of accessing random, misdocumented, randomly limited, arbitratily formatted subset of that which slowly bit-rots.
FridgeSeal 5y ago
As opposed to a bunch of websites serving an archaic, poorly formatted blob of text-the “correct” parsing of which has now become _so complicated_ that it’s basically infeasible for anyone not willing to build a whole web-browser?
- cxr 5y ago
  Parsing is not the hard part of dealing with the Web platform.
  - regularfry 5y ago
    It's certainly not the easy part.
    - deleted 5y ago
      [deleted]
luckystarr 5y ago
Yes, it's still terrible for the consumer of the data. But I like it not because of that. The positive thing I feel when reading about this, is that it dramatically lowers the barrier for the producer of the data to expose it in a meaningful way. While previously it was necessary to think about the format and write code to expose the data while now its possible to just throw the data over a wall. You could use a framework to automate the first thing, but this would be specific to one programming language, while the second approach works with all languages. So it lowers the total effort to get to the goal, effectively side-stepping the "have to implement framework or serialization code" issue. Warning: heavy speculation below So if more people would build sites using this technique, the pressure for better tools (at a higher level than right now) for consumers would increase, so these would be built by someone. As you have a proper standard (there is only one SQLite) you would have a new "ecosystem" growing. This would lower the pain for the consumers of said data. You'd still have to implement it in every programming language that wants to access the data, but this is another problem.
mrpf1ster 5y ago
I disagree, the alternative is either no access to website data or access through a tightly controlled API (which can come with the same problems if API compatibility is not guaranteed).
webmaven 5y ago
> Terrible idea. Why would anyone want to deal with interfacing a bunch of randomly structured databases whose tables can change at any time without warning. Nightmare. It isn't quite so bad. You can have wiki-esque volunteer-driven cooperative authoring, linking to known good versions, etc. to keep it from becoming a complete free-for-all.

by togaen 5y ago

Terrible idea. Why would anyone want to deal with interfacing a bunch of randomly structured databases whose tables can change at any time without warning. Nightmare.

scotty79 5y ago

Not when compared to alternative of accessing random, misdocumented, randomly limited, arbitratily formatted subset of that which slowly bit-rots.

FridgeSeal 5y ago

As opposed to a bunch of websites serving an archaic, poorly formatted blob of text-the “correct” parsing of which has now become _so complicated_ that it’s basically infeasible for anyone not willing to build a whole web-browser?

cxr 5y ago
Parsing is not the hard part of dealing with the Web platform.
- regularfry 5y ago
  It's certainly not the easy part.
  - deleted 5y ago
    [deleted]

luckystarr 5y ago

Yes, it's still terrible for the consumer of the data. But I like it not because of that. The positive thing I feel when reading about this, is that it dramatically lowers the barrier for the producer of the data to expose it in a meaningful way. While previously it was necessary to think about the format and write code to expose the data while now its possible to just throw the data over a wall. You could use a framework to automate the first thing, but this would be specific to one programming language, while the second approach works with all languages. So it lowers the total effort to get to the goal, effectively side-stepping the "have to implement framework or serialization code" issue. Warning: heavy speculation below So if more people would build sites using this technique, the pressure for better tools (at a higher level than right now) for consumers would increase, so these would be built by someone. As you have a proper standard (there is only one SQLite) you would have a new "ecosystem" growing. This would lower the pain for the consumers of said data. You'd still have to implement it in every programming language that wants to access the data, but this is another problem.

mrpf1ster 5y ago

I disagree, the alternative is either no access to website data or access through a tightly controlled API (which can come with the same problems if API compatibility is not guaranteed).

webmaven 5y ago

> Terrible idea. Why would anyone want to deal with interfacing a bunch of randomly structured databases whose tables can change at any time without warning. Nightmare. It isn't quite so bad. You can have wiki-esque volunteer-driven cooperative authoring, linking to known good versions, etc. to keep it from becoming a complete free-for-all.