Skip to content

Initial implementation #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

masylum
Copy link
Contributor

@masylum masylum commented Nov 16, 2015

🎩 What? Why?

First prototype to support https://github.com/ipfs/specs/tree/master/repo
Implemented part of fs-repo adapter by using fs-blob-store, paving the way
for browser-compatible blob stores (@somebody32 working on it)

👻 GIF

^ streams

@masylum
Copy link
Contributor Author

masylum commented Nov 16, 2015

@somebody32 I removed babel because it was slow and got tired of it, the code looks all-right anyway

@masylum
Copy link
Contributor Author

masylum commented Nov 18, 2015

@diasdavid would be nice if you could take a look at the initial proposal to be sure I'm on the right way

var LOCK_PATH = this.LOCK_PATH

function onFinish (buff) {
lockFile.unlock(LOCK_PATH, function () {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing error handling

return this._write(key, content, 'a', cb)
},

write: function (key, content, cb) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to also offer a stream interface

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, initially I was returning the write stream but it got lost when implementing the locks. Will create a richer API as I move forward.

@daviddias
Copy link
Member

Seems you are in the right direction :) I like that the interface revolves the several types of data stored in the Repo. It would be good to start having tests for the experiments you are doing, so other people feel confident to PR too.

You had some thoughts on how repo should be structured on disk, might wanna share with @whyrusleeping before 0.4.0 release, since 0.4.0 has a different repo structure already, it will be the perfect time for other significant migrations.

@masylum
Copy link
Contributor Author

masylum commented Nov 18, 2015

Is there anywhere I can see what's planned in the 0.4.0 release? I've reached a point where I will have to start reverse-engineering the go implementation though since specs and reality don't seem to match (opened ipfs/specs#41)

@jbenet
Copy link
Member

jbenet commented Nov 19, 2015

@masylum I'm sorry about that, I really need to fix the spec there to
reflect go. :c

I think we can move the nesting to be 3 levels in go-ipfs but some other
stuff is better than I need to materialize here.

If anybody wants to help me writing this stuff up it would be sweet.
On Wed, Nov 18, 2015 at 04:01 Pau Ramon Revilla notifications@github.com
wrote:

Is there anywhere I can see what's planned in the 0.4.0 release? I've
reached a point where I will have to start reverse-engineering the go
implementation though since specs and reality don't seem to match (opened
ipfs/specs#41 ipfs/specs#41)


Reply to this email directly or view it on GitHub
#1 (comment).

@whyrusleeping
Copy link
Member

@masylum
Copy link
Contributor Author

masylum commented Nov 25, 2015

I moved forward with the prefix as it is in go-ipfs. If the spec materializes in some other way is easy for me to change it back.

Added a memory-repo dummy implementation which will allow me to start testing easily. It will also help me define a fs agnostic API (I still have my doubts whether repo.lock should belong to repo or fs-repo).

I also will need some guidance with the rest since I'm not sure I understand the datastore folder.

@daviddias daviddias mentioned this pull request Nov 30, 2015
14 tasks
@jbenet
Copy link
Member

jbenet commented Dec 1, 2015

@masylum sounds good to me.

re the repo.lock, i responded in the spec. gist is that yes, that probably should be removed from repo spec.

@daviddias
Copy link
Member

@masylum you have write perms on this repo, mind if you do a PR to a branch in this repo and then a PR to master, so we can work together without having to PR the PR the PR :)

@daviddias
Copy link
Member

I went ahead and moved the PR to be a branch on the main repo, so it enables easier collaboration - #2. Closing this one.

@daviddias daviddias closed this Dec 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants