You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At this point I'm pretty sure the MFS Root structure can be refactored out (#5066) so I would like to concentrate on abstracting the common characteristics of the Directory and File structures, which are many: parent, name, dserv, lock/nodelk, maybe node (in the directory it is hidden behind the dirbuilder which could maybe also be refactored out #5084). What those two structures should reflect is only what makes a file different from a directory in an MFS context: a file has content that can be modified and a directory has (what could also be denominated as content) entries (links) of other files and directories.
What I would like to discuss is how to encapsulate that common functionality, could we adopt the Unix terminology of a file that can be a directory or a regular file? (which I never really liked as the file term ends up carrying too much conflicting meaning, but can't think of anything else)
The text was updated successfully, but these errors were encountered:
At this point I'm pretty sure the MFS
Root
structure can be refactored out (#5066) so I would like to concentrate on abstracting the common characteristics of theDirectory
andFile
structures, which are many:parent
,name
,dserv
,lock
/nodelk
, maybenode
(in the directory it is hidden behind thedirbuilder
which could maybe also be refactored out #5084). What those two structures should reflect is only what makes a file different from a directory in an MFS context: a file has content that can be modified and a directory has (what could also be denominated as content) entries (links) of other files and directories.https://github.com/ipfs/go-ipfs/blob/7853e53860805e08a212d78c4baa5d59bff99ba8/mfs/dir.go#L26-L41
https://github.com/ipfs/go-ipfs/blob/fc05376e94125b854e2b837760c44aacbaa97e2d/mfs/file.go#L16-L28
What I would like to discuss is how to encapsulate that common functionality, could we adopt the Unix terminology of a file that can be a directory or a regular file? (which I never really liked as the file term ends up carrying too much conflicting meaning, but can't think of anything else)
The text was updated successfully, but these errors were encountered: