sirnewton01 / ghfs Goto Github PK
View Code? Open in Web Editor NEW9p GitHub filesystem written in Go for use with Plan 9/p9p
License: Other
9p GitHub filesystem written in Go for use with Plan 9/p9p
License: Other
The current multi-line text boxes are surrounded by code fences using the back-ticks. The textual representation is ugly and it causes escaping difficulties in the Go code.
Instead, several tildes could be used with a much better visual effect. Tildes as code fences appears to be part of the original standard and a variable number of them could be used to help and avoid escaping collisions within the descriptions.
Also, the three underscores after the block are unnecessary and waste vertical space. Instead, if there is a fenced code block the variable should be bound to the literal contents of the block. There should be no need for them in this case. They should remain for the single-line text case though as they serve as a good visual cue and it is sometimes unclear where the end of the text should be.
A number of the handlers and even the server itself allow modification of its state from multiple threads without any explicit synchronization. This is bad because it can lead to subtle data corruption problems. The code should be fixed up before we begin to have any true editing capabilities so that users are certain what they are editing.
The issues directory could use an overview file that allows you to see the issues, summaries, owners and last modified dates at a glance. You can open each issue using a link in the table. The table can be filtered using the filter.md used to populate the issues directory but with some guidance on how to use it. In the future this overview could be used to provide an entry point to create new issues.
Allow a user to edit the repo.md in their text editor and effect changes to the project metadata provided that they have permission.
Under the owner folder it would be good to have an activity feed to see what you or anyone else has done.
When attempting to change the label on an issue and you don't have permission no error is produced. The file saves fine but there is no change to the labels.
Allow a search file to be written with search criteria. The results can come back with file paths and commits where the matches were found allowing you to use a git tool to find them.
I'm getting the error
# github.com/sirnewton01/ghfs/dynamic
dynamic/server.go:369:5: undefined: protocol.Debug
dynamic/server.go:370:8: undefined: protocol.DebugServer
when trying to build on a Mac.
There doesn't seem to be any way to get the blackfriday dependency to clone on 9front. dgit crashes, and the git rc script says the url is not supported.
When a client is writing a file, they may divide their writes into blocks if the file is beyond a certain size. There's no real way to know when they are done writing except when they "clunk" the FID they used to write. At the moment, simple cases like the ctl file in the issues directory are assuming a single write and immediately attempt an update after that write. In that case, the file is usually so small that clients write the buffer in one shot. However, with larger items the client may break it up.
The dynamic server should expose the FID used to open on writes so that handlers can detect when clunking the writes to that FID in order to perform an update or produce an error if the update fails. Also, the issues ctl file should adopt this approach.
Provide a way to write to a search file and get back a new file with the results and links to the issues that match. The issue links will be simple file path links allowing you to navigate using acme to the issue easily and perhaps even navigate to the matching text/line number.
There should be a file that dynamically loads the commits is descending order. The file is conceptually limitless, loading on-demand as a reader reads it allowing the user to make use of a pager. There is no need to support a tail/head command.
It should be possible to edit an issue by modifying the text in the markdown document provided that I have permission. Also, there will be a comment template at the bottom to allow me to easily fill it in and create a new comment on the issue.
To create a new issue a variant of the clone file used in other Plan 9 filesystems can be used. When you open the clone file you see an issue template that allows you to fill it out easily. Once you write to the clone file it creates the issue.
If we were to follow the typical Plan 9 pattern for clone files, the write to the clone file causes it to rename itself dynamically to the new file. However, it is unclear how well text editors can handle the renaming of the file on the fly with the same QID/FID. It is possible that they won't handle it well. But, at least modifications and subsequent saves won't create new issues.
A workaround could be to have writes to the clone file produce a message somehow that "2.md has been created" so that in acme at least the user could navigate to it with a right click. It seems that the only way to do this is to have the clone file always return a Terror on write, which is very confusing semantics.
Another workaround is to have the write to the clone file succeed and have the user manually open the new issue, which is not super usable but the semantics are better. It could be solved with a bit of inline documentation ("Check the issues directory for your new file after you save").
It is useful to be able to change the sort order on this file. The filter.md should support changes to the list query that affect not only the content but the sort order. This sort order would impact only the 0list.md file and not the directory listing. There should be a note made in the filter.md that those settings only affect the 0list.md file.
The graphviz format can be used to render graphs for the forks of a repo. It's also fairly readable in its text form, which is consistent with the rest of the ghfs design.
Only open issues are displayed, there's no way to read issues after they've been closed.
Maybe the issues directory should have new/closed/all subdirectories to match the possible states in the GitHub API?
Provide the ability to follow or unfollow other users, which would affect the activities and the default owners that show up under /repos.
The current ctl file is JSON, mapping directly to the object used in the ListByRepo query. Instead, there should be a markdown conversion to/from this object so that the markdown can have helpful comments on how to use the different flags. Also, the markdown can skip the properties that have no effect when the user tries to customize them, such as the page size used to transfer the issues and the sorting order.
It would be nice if there was a way to issue a PR, since you can't do it with the standard git command line.
Due to the excessive chattiness of OSes when they go through FUSE and the odd bug in ghfs there can be quite a few round trips with GitHub retrieving the same data over and over. I haven't seen a case yet where I went over the rate limit, but it does slow things down. The go-github library does mention that there is a way to hook up an HTTP cache with another go library and it will make use of the ETag and IF-Matches headers along with a cache to avoid the round trips. Another option, that is much more Unix/Plan 9 in philosophy would be to set up a proxy that does the caching and ETag checking.
In either case this setup should be documented in the README to help people to make it work in their setup.
This becomes really useful when you are looking at issues and want to view/sort them according to how old they are or if there is recent activity.
You can do a simple ls -l
to browse them yourself or even sort them using ls -lt
or ls -Ult
There should be a way to watch, unwatch or completely ignore repos.
When a repo is forked, it currently shows that it is forked but there is no way to know what repo it was forked from. It would be good to have that as a path you can easily navigate on to drill down to the original repo.
When browsing users or organizations with a very large number of repos such as google or mattn the directories are showing up as empty.
Allow a user to change the title of an issue or the description. Also, there should be a template at the bottom of the comments that they can fill in to create a new comment.
When I look at the issues for a project I'm also seeing pull requests. Either the directory name should be updated to reflect this, pull requests should be filtered out initially unless requested or some kind of documented workaround should be in place. It is rather interesting that the GitHub REST API lumps the two together.
It would be great to be able to have a directory or directories related to topics. They would be empty by default like "/repos." The repo.md for a particular repo would have links in to topics that are tagged for the project.
Some thought needs to go into how to handle paging. A topic could be a single file or a directory with files in it.
With a single file, it could be infinitely scrolling but then most text editors probably won't handle it well even if a pager or the plan9 command line might. The file could be writable, which would provide the trigger for the next page, but there are no universal reload semantics.
A topic could be two files. One for the content and another "control" file to expand its size. The workflow wouldn't be too dissimilar from the issue filters workflow with the issues file. The user needs to know to reload the content file after touching the control file.
Alternatively, a topic could be a directory with a control file exactly like the issue.
Another option is to divide pages for a topic among different incrementing page files. Open the first "001.md" and it shows the first page, "002.md" for the second, etc. "cat *.md | more" on the directory will give you a single page. Editors open one at a time with a link to the next at the bottom.
It would be good to show at least the top-level contents of a repo, which usually includes a readme, license information and other information that can provide a lot of context when browsing different repos. It will be good to show the contents under a hierarchy that represents the different branches or tags.
It will be useful to have the starred repos visible at a glance so that you can easily navigate back to them amongst the user's other repos that are of no interest.
Perhaps it doesn't really make sense for ghfs to run in unauthenticated mode. If this capability will continue to be supported then this bug should be fixed.
It would be good to have a feed of the activity of a particular repo so that you can see if there is any current work happening there.
When navigating to a large organization (e.g. google or microsoft) it is very slow to iterate through the hundreds of repos. It blocks acme and continue to bog down ghfs after the the owner is loaded. The performance should be analyzed to consider any optimizations that may be possible.
Also, perhaps the loading of all of the repos for large organizations should be reconsidered. It wculd be worthwhile to load only the first 50/100 and allow the user to access specific named repos afterwards. If the user truly wants to look at all of the repos then there could be a special file (more) that can be opened to cause all of the repos to be loaded.
There's a good chance that users you watch will have repos that are interesting to you. They should be automatically populated in the repos directory so that you can easily navigate to their repos.
Certain repositories are missing the repo.md with the metadata and actions, like star and watch. An example is this one: https://github.com/paul-lalonde/twittergo
There is a very good chance that the logged-in user will want to see their repos right away and so we should automatically show it under repos. Other repos will show up on-demand as usual and by navigating cross-links or by direct navigation to a specific place.
If you watch another really large owner of repos it takes a very long time to list your own repos and access your own items with plan9port on Mac. This should be optimized in some way to avoid this hit when it is not needed.
The README.md in the repo directory doesn't show whether the project is a fork. If it is a fork it doesn't show the original repo.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.