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

API variations comparing go vs js versions #295

Closed
@MasterJames

Description

@MasterJames

I noticed some variations of the API comparing the videos and I guess it's the go lang version to this js-ipfs version. For example...
Typing just jsipfs reports various possible commands

...
files add                 Add a file to IPFS using the UnixFS data format
files cat                 Download IPFS objects
files get                 Download IPFS objects
...

while add, cat and get are not prefixed with files in the regular version.
same with files being called file, or is that file being called files here vs there.

Leads one to question what the WebGUI API follows etc.?

Is it not suppose to follow the existing API? What's happening there?

Maybe there's a plan to use this API instead, like its some experimental exploration dev version?
https://youtu.be/h73bd9b5pPA?t=4746

Maybe it's a typo with file(s) and it's missing add & cat aliases?
Maybe there will be both file and files? not that that won't be too confusing.

I thought to mention how the MikroTik RouterOS uses a '/' slash prefix with commands and then they are relative path (if no prefix slash on subsequent commands). It's not very unixy but an interesting thought. More so when thinking about how code and DAG folders could possibly work this way in a relative folder-check for commands like some CLIs do. An executable search through current/working folder/directory/dag before going to the official shell's 'path' (config setting?) or parents etc. I do this when searching for database keys so one can have a default folder as well as in the parent, but that's another story/idea to think about.
[ Add the idea of a best match key search, example: w matches width, if only width and height found, if not found check parent and/or default folder for possible matches. Kind of a regex but probably faster dictionary (aka js object) key search, as only w is needed to match width and the entire key's length doesn't need pairing-off/matching. Again better for another suggestion posting later, maybe. ]
This is what I've been thinking too
https://youtu.be/h73bd9b5pPA?t=4784
inject above idea into those conversations.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions