blahah
commented
8 years ago My feeling is that slides should be kept as flat markdown files. They already contain all the information needed to form a collection. The idea is that a user should be free to add or edit slides in the plaintext markdown, and the slidewinder simply works with the collection. One of the best things about flat files is they can be put on the internet, e.g. on github, or just on a website, and easily accessed with no special API.
When I started slidewinder I also registered slidewinder.io. The idea is that the site is a huge repository for open slides and decks, and that you can connect to it with slidewinder and rapidly find and assemble slides into decks. I plan to add to slidewinder the ability to 'eat' existing decks, and to do some content mining of the bioinformatics literature and to parse every figure from an open licensed bioinformatics paper into a slidewinder slide. Then put them all on slidewinder.io! Users will be able to add slides on the site, add them from the command-line, and to add links to repositories like the biojulia one we are planning to make, and they will all be accessible via the search interface.
To get (tens of)thousands of slides being managed effectively, it will be necessary probably to add them to a database - elasticsearch is the clear winner for search capability, but I think that will only be necessary on the site, not for the cli. The site will probably watch all the remote repositories it links to for updates, and load new stuff into the database when it gets added.
Thoughts?
TransGirlCodes
Opening issue to discuss management of content - slide/asset collections, presentation generator plug-ins and so on. The method I have originally thought of was through nedb - which isn't so much a full blown database system, but a way of storing small - by internet standards - set of data in some files, which really just JSON underneath. I'm open to other db systems and methods - sharing slides like dat shares data would be a cool future possibility, but for now I thought doing this through nedb and a few nedb/json files in a dotfolder was beter then doing it by many individual files and prescribed/assumed directory structure in a dotfolder or elsewhere, which could easily me modified by the user and screwed up, with a few json nedb files there's less for a user to mess up.
But tell me what you think about content management - I know you've had some ideas and thoughts. Mine is only one idea, which seemed to make sense for local persistent storage.