Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

config #49

Closed
14 tasks done
daviddias opened this issue Jan 14, 2016 · 10 comments
Closed
14 tasks done

config #49

daviddias opened this issue Jan 14, 2016 · 10 comments
Assignees
Labels
exp/novice Someone with a little familiarity can pick up

Comments

@daviddias
Copy link
Member

To learn more about config, you can

Implementation Roadmap

@daviddias daviddias changed the title features: config feature: config Jan 14, 2016
@daviddias daviddias added the exp/novice Someone with a little familiarity can pick up label Jan 26, 2016
@daviddias
Copy link
Member Author

config http-api spec - ipfs-inactive/http-api-spec#29

@RichardLitt
Copy link
Member

Let me know if the spec needs updating.

@daviddias daviddias changed the title feature: config config Feb 23, 2016
@daviddias
Copy link
Member Author

updated this issue

@fbaiodias
Copy link
Member

@diasdavid I was looking into jsipfs config edit but couldn't find any way of accessing the repo's config file path.
Should we expose it on js-ipfs-repo or did I miss something?

@daviddias
Copy link
Member Author

@xicombd note that the jsipfs cli might be working through the network, so essentially the way to do it is to fetch the config, open it on a editor and when on save, write it back.

@fbaiodias
Copy link
Member

Ahhh, makes sense. Thanks for the clarification!

@fbaiodias
Copy link
Member

I'm implementing the /config/replace api endpoint, but although it works fine with the spec's curl example, and the hapi tests, I'm not being able to use it with js-ipfs-api.

I'm calling it like this (see the test):

const file = 'tests/otherconfig'
ctl.config.replace(file, (err, res) => {
  console.log(err, res)
})

And hapi is replying with:

 { statusCode: 400, error: 'Bad Request', message: 'Invalid multipart payload format' }

@diasdavid @dignifiedquire do you have any idea how to make this support js-ipfs-api? Or should we change js-ipfs-api instead, and send the files in another way?

Thanks!

@daviddias
Copy link
Member Author

"multipart strikes again™"

@xicombd good catch, we certainly need to document that, the reality is that go-ipfs uses a custom made Multipart message format which hapijs is rejecting since it expects something with the format of the spec. This might require some hackery in order to get the same Multipart parser that we have in Go.

A way to get this done is

    1. capture a multipart message for file and one for a dir created by go-ipfs cli or js-ipfs-api
    1. built the same custom js parser for that custom multipart message, as we have in go-ipfs (https://github.com/ipfs/go-ipfs/tree/master/commands)
    1. integrate it with hapijs

@daviddias
Copy link
Member Author

https://public.etherpad-mozilla.org/p/multipart-madness

js-ipfs hacking

const multipart = require('ipfs-multipart')

server.route({
     method: ‘POST’
     path: '/files/add'
handler: (req, res) => {
     req.pipe(multipart.parser)
          .on(‘file’, (filename, filestream) => {
          // filename is the entire filepath
                }) 
                .on(‘err’, (err) => {

                 })
 }
})

TODO

  • fork hapi and add option to skip the payload read/parse for a route for a given route
  • make PEZ understand our multipart messages

NOTES

Hapi passes the request.raw.req here https://github.com/hapijs/subtext/blob/master/lib/index.js#L296 to subtext, that pipes it to pez here: https://github.com/hapijs/subtext/blob/master/lib/index.js#L429

@fbaiodias
Copy link
Member

Started implementing a multipart parser for ipfs here: https://github.com/xicombd/ipfs-multipart

MicrowaveDev pushed a commit to galtproject/js-ipfs that referenced this issue May 22, 2020
* feat: convert to async/await

BREAKING CHANGES:

1. Everything is now async/await
2. No more callbacks, Readable Streams or Pull Streams
3. `stat` and `ls` commands return `cid` objects instead of string hashes
4. `stat` and `ls` commands return all fields, `hash`, `long` etc options are now ignored

* chore: standardise error codes, use latest cids and ipld formats

* chore: update importer and exporter

* chore: update importer again

* chore: update deps
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/novice Someone with a little familiarity can pick up
Projects
None yet
Development

No branches or pull requests

3 participants