"...inspired by the elegance and power of Git for years.." Definitely powerful, but elegance?
If you ever look into the internals of how Git works, it is beautiful. Yeah, the UI is kinda a mess, but the idea is inspired.
"UI is kinda a mess" - amen.
Show HN: Noms – A new decentralized database based on ideas from Git
171–180 of 180 posts
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#172Earlier quoted context omitted.
Hmm, if you want people to be able to link to Noms datasets on the web, maybe you should switch to using URLs to name the datasets, instead of a two-part identifier with an URL separated from a dataset name by a "::"? Darcs and Git seem to get by more or less with URLs and relative URLs; do you think that cold work for Noms too? The super REST harmonious way to do this would be to define a new media-type for Noms dat…
This is a good point. We never thought of these strings as URLs, but there are places where it would be nice to use them that only want URLs (the href attribute, for example). The way we have it now is nice in that any valid URL can be used to locate a database. I am loathe to restrict that. Interesting point though - thank you!
Sure, I hope the ideas are useful! As some other commenters have said, if you just use # instead of ::, I think the problem goes away?
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#173Earlier quoted context omitted.
This is a good point. We never thought of these strings as URLs, but there are places where it would be nice to use them that only want URLs (the href attribute, for example). The way we have it now is nice in that any valid URL can be used to locate a database. I am loathe to restrict that. Interesting point though - thank you!
Sure, I hope the ideas are useful! As some other commenters have said, if you just use # instead of ::, I think the problem goes away?
The hash portion of a URL is not transmitted to the server by browsers, so it wouldn't help in the case of putting the string into a URL bar or a hyperlink.
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#174Earlier quoted context omitted.
Sure, I hope the ideas are useful! As some other commenters have said, if you just use # instead of ::, I think the problem goes away?
The hash portion of a URL is not transmitted to the server by browsers, so it wouldn't help in the case of putting the string into a URL bar or a hyperlink.
If the resource you're linking to is a database (or to speak more strictly, if its only representation is a resource of a noms-database media-type), rather than an HTML page or something, can't the browser can be configured to pass it off to a Noms implementation, complete with the dataset identifier within? I mean, that's what people do with page numbers in PDF files, right?
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#175Earlier quoted context omitted.
The hash portion of a URL is not transmitted to the server by browsers, so it wouldn't help in the case of putting the string into a URL bar or a hyperlink.
If the resource you're linking to is a database (or to speak more strictly, if its only representation is a resource of a noms-database media-type), rather than an HTML page or something, can't the browser can be configured to pass it off to a Noms implementation, complete with the dataset identifier within? I mean, that's what people do with page numbers in PDF files, right?
Hm. True.
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#176This looks really interesting. I've been thinking about the problem of distributed issue tracking lately... and the set of sub-problems it has (authorization and authentification, synchronization and so on) ... I'm not sure all these problems could be covered by this, but I guess at least the "distributed"-part could be covered by something like this.
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#177First off... I'm excited to see this project. There's a lot of potential here and this looks like a good implementation of a nice concept. I have at least a bit of authority behind that statement, since a few years ago, I had the opportunity to build something similar (although smaller in ambition.) A couple things to think about: * Type accretion - This doesn't change the fact that database clients need to be able t…
- Type accretion: I don't think in general that schema changes like what happens in sql databases works very well (I say this having worked on such systems). In big systems, it's hard to get everyone to agree on a moment to CHANGE THE SCHEMA. You can certainly do something like that in Noms -- just write a new dataset and replace the old one. But being able to read old data and leave old clients working I think is powerful. Couple this with the structural typing that falls naturally out of Noms and - I think - you have a more flexible way to change schemas over time.
- Security: current thoughts: https://github.com/attic-labs/noms/issues/1183
- Perf: I'm not really following you here. CAS has some positives and some negatives for performance.
- expiration: 1. there are a huge number of systems today that never delete data. Taking advantage of that to make other operations faster makes sense. 2. yeah, it's a gc problem. luckily gc is a well-studied problem. Also, as Noms is a merkle tree and merkle trees are good at diff, we have some additional leverage. We don't need to do a full scan everytime.
- querying: disagree that it is essential to perf. Another option is to have a schema that matches your access model. You can do that server-side in addition (or instead) of having a query language.
===
It sounds like you have thought a lot about all of this! If you are interested, your brain would be very appreciated in the github or slack.
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#178I'm curious about merging. When there is a conflict, like when a file gets changed by different people, how merging is performed?
Not implemented yet, but here is the plan: https://github.com/attic-labs/noms/issues/148
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#179First off... I'm excited to see this project. There's a lot of potential here and this looks like a good implementation of a nice concept. I have at least a bit of authority behind that statement, since a few years ago, I had the opportunity to build something similar (although smaller in ambition.) A couple things to think about: * Type accretion - This doesn't change the fact that database clients need to be able t…
- Type accretion: I don't think in general that schema changes like what happens in sql databases works very well (I say this having worked on such systems). In big systems, it's hard to get everyone to agree on a moment to CHANGE THE SCHEMA. You can certainly do something like that in Noms -- just write a new dataset and replace the old one. But being able to read old data and leave old clients working I think is po…
> It sounds like you have thought a lot about all of this!
Up until around 2014, I was heavily involved in the construction of a small CAS (100MM objects online, around 5-6TB in size) for a client that needed to replicate certain periodic calculations in a reliable way. It worked well, but something like noms would have eliminated the need for a bunch of custom work.
> If you are interested, your brain would be very appreciated in the github or slack.
I'll take a look... thanks for the invite!
Re: Show HN: Noms – A new decentralized database based on ideas from Git
#180First off... I'm excited to see this project. There's a lot of potential here and this looks like a good implementation of a nice concept. I have at least a bit of authority behind that statement, since a few years ago, I had the opportunity to build something similar (although smaller in ambition.) A couple things to think about: * Type accretion - This doesn't change the fact that database clients need to be able t…
- Type accretion: I don't think in general that schema changes like what happens in sql databases works very well (I say this having worked on such systems). In big systems, it's hard to get everyone to agree on a moment to CHANGE THE SCHEMA. You can certainly do something like that in Noms -- just write a new dataset and replace the old one. But being able to read old data and leave old clients working I think is po…
[deleted]