61–70 of 180 posts
Going through the SDK docs, why was a scheme like ' http://localhost:8000::people' chosen instead of the plain old ' http://localhost:8000/people' ? Are there any benefits? If yes, curious to know what they are.
In this case, we need to be able to address either a database and a dataset. The presence of a :: makes it unambiguous.
Strawman marketing alert: "The most common way to share data today is to post CSV files on a website". Maybe there are a bunch of people that still do that somewhere, but if so, they ain't early adopters of decentralized database technology and so not your target customers. It's always better to talk about what your most likely customers are doing now.
For example, if you browse the UC Irvine ML datasets
https://archive.ics.uci.edu/ml/index.html
You'll find that many are in csv format.
If you do a search on data.gov
http://catalog.data.gov/dataset#sec-res_format
You'll see that it's about as popular as JSON.
Also, the World Health Organization
http://www.who.int/tb/country/data/download/en/
Also, many of the datasets at kaggle are in csv format.
https://www.kaggle.com/datasets
And this isn't that surprising, it's human readable, and gets the job done, and zipping will give decent compression.
I'm not sure who you think the target market for this would be, but I'm sure that if it's an efficient local format, you could probably get the ML crowd on board.
Strawman marketing alert: "The most common way to share data today is to post CSV files on a website". Maybe there are a bunch of people that still do that somewhere, but if so, they ain't early adopters of decentralized database technology and so not your target customers. It's always better to talk about what your most likely customers are doing now.
Strawman marketing alert: "The most common way to share data today is to post CSV files on a website". Maybe there are a bunch of people that still do that somewhere, but if so, they ain't early adopters of decentralized database technology and so not your target customers. It's always better to talk about what your most likely customers are doing now.
This is actually extremely common. For example, if you browse the UC Irvine ML datasets https://archive.ics.uci.edu/ml/index.html You'll find that many are in csv format. If you do a search on data.gov http://catalog.data.gov/dataset#sec-res_format You'll see that it's about as popular as JSON. Also, the World Health Organization http://www.who.int/tb/country/data/download/en/ Also, many of the datasets at kaggle are…
Also, we routinely talk to developers who complain about the difficulty of consuming data snapshots from partners, parsing it, trying to understand how it has changed since last time, etc.
With high value datasets, people frequently build an API to combat these problems. But it's hard to design a good API, and even if you succeed, it has to be secured, documented, scaled, and maintained indefinitely.
Going through the SDK docs, why was a scheme like ' http://localhost:8000::people' chosen instead of the plain old ' http://localhost:8000/people' ? Are there any benefits? If yes, curious to know what they are.
Perhaps they were writing so much in Go that they set the '/' key to shortcut to '::'. ...but yeah, I am also curious.
Earlier quoted context omitted.
This is actually extremely common. For example, if you browse the UC Irvine ML datasets https://archive.ics.uci.edu/ml/index.html You'll find that many are in csv format. If you do a search on data.gov http://catalog.data.gov/dataset#sec-res_format You'll see that it's about as popular as JSON. Also, the World Health Organization http://www.who.int/tb/country/data/download/en/ Also, many of the datasets at kaggle are…
Right. A shocking amount of public data is distributed this way. Also, we routinely talk to developers who complain about the difficulty of consuming data snapshots from partners, parsing it, trying to understand how it has changed since last time, etc. With high value datasets, people frequently build an API to combat these problems. But it's hard to design a good API, and even if you succeed, it has to be secured,…
or would it be 'use this hostname to sync the nom to your own computer'
Or would it be a dsn sort of and you just instantiate a client and your on your way?
Or, some combo?
Earlier quoted context omitted.
We never chunk the same data differently. An inviolable rule of Noms is that the same logical value is always chunked the same way and always has the same hash. If I start with integers 1-1000000 and you start with integers 0-999999, and we both make mutations to converge at the same list, we will end up with the exact same tree, with the exact same hashes. This is what makes efficient synchronization and diff of nom…
Thanks. So it's building a hash tree with deterministic chunking and that means you can cheaply update the hash after updating parts of the tree as you only have to rehash certain bits? Does that mean that your chunk sizes are kind of fixed? Do you think there's a way to retain that advantage and be able to coalesce smaller chunks into larger ones? Say your smallest nodes are 4KB but for more efficient storage you mi…
In any case, that's a good question - we might want to do something about that down the line. But, if we did change that constant, the structure of the trees will change, and all[1] the hashes will change.
[1] a small number will stay the same
How do you handle hash collision?
Going through the SDK docs, why was a scheme like ' http://localhost:8000::people' chosen instead of the plain old ' http://localhost:8000/people' ? Are there any benefits? If yes, curious to know what they are.
Should have thought about compatibility before making up a naming scheme.
Going through the SDK docs, why was a scheme like ' http://localhost:8000::people' chosen instead of the plain old ' http://localhost:8000/people' ? Are there any benefits? If yes, curious to know what they are.
See https://github.com/attic-labs/noms/blob/master/doc/spelling.... - In this case, we need to be able to address either a database and a dataset. The presence of a :: makes it unambiguous.