-
Notifications
You must be signed in to change notification settings - Fork 72
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
add neighbor seeding #18
Conversation
An interesting idea. Removing the reliance on site entry point / navigation route as the sole criteria for determining which sites are in the current neighbourhood. While a single static pre-defined neighbourhood, at server start, is interesting I think this is probably only a start. I can't help but wonder if making this dynamic, and site specific, would be more interesting. Probably making it a specific 'page' and using the reference plug-in to define a site's seeded neighbourhood. Making it a page, rather than defined at server start, makes it visible as something that can be shared, forked, and managed by a community. |
This seems to address a bootstrap problem for site operators that want to host a farm for a specific community. Mike Caulfield comes to mind. At one time I had the default Welcome Visitors page include a journal reference to fed.wiki.org so that the How To Wiki pages would be accessible. This became annoying "pollution" of the Recent Changes. This feature would pollute similarly but that might be the site operator's desired behavior. I later placed a copy of How To Wiki in default pages where it could be found. This wouldn't be the most recent version, but twins would announce newer versions. https://github.com/fedwiki/wiki-node-server/tree/master/default-data/pages This proved adaquate for bootstraping documentation. |
I've been having Students add a "Related Sites" portion to their Welcome page: http://mits.wsuv.wiki:3000/view/welcome-visitors In this case they can load "All Students" or just the students from their local group. The ability to only load subsets is important. We have been calling these pages we load "circles", as in "Load your groups circle into your neighborhood". This works great once it's running. But bootstrapping problems include:
I'm not sure I fully understand the proposal -- would all sites on the server be seeded? If so that's too much. But if I'm reading it correctly, the ability to seed a chosen site like sites.fed.wiki.org along with another wiki that provides a hand-crafted annotated directory would be awesome. I'd put both the group pages and the all student pages there, and then I'd just tell students what links to add under Related sites. |
So the main thrust of the three pull requests, and the part that I really think needs to happen, is the ability to seed chosen sites using startup options. Seeding sites.fed.wiki.org is a great example, that and the root page of the current farm might be the two most useful. This pr also has a bit that is pretty questionable, seeding every site currently running in a farm to every other site currently running in the farm. When I was working on the first part, I realized I could do the second part and wanted to float it out there as a possibility :) |
Whoops, good catch @paul90, thought I tested that. Will correct it tonight. Do we want to pull the automatic farm seeding magic out? |
The farm seeding magic is interesting because it does something without further configuration. But I can see how the current magic might be annoying in some situations. Can we put it behind an option too, and maybe suggest that the magic might improve? |
Sounds like a good plan. |
That commit also fixes the unknown site bug from above. |
Looks good - some interesting comments from @michaelarthurcaulfield that will no doubt generate some future changes in this area. |
Add command line description for neighbors, and add a list of servers currently running on the farm to the neighbors list for all servers on the farm. This is an interesting idea I'd like to get everyone's input on, but it might not be the desired behavior.
This PR is not necessary for the other two to be merged and function as intended.