Replies: 1 comment 1 reply
-
TLDR: Plugin system good. Decoupling base UI & book scrapers not so much. Theme plugins doable and in fact pre-planned for. See below for the non TLDR version.
The base of the project is the book scraping system. This can technically be considered the third part of the project I worked on. The first part would have been the configuration module, followed by the Installation module. The installation module is no longer a part of the project as i phased it out back when i introduced docker support. A Month was spent on the installer alone. The configuration module is tied into the backend part and parcel. Though it can be actually be used on its own in other projects quite easily. At one point pyshelf had a complete cli. It does not have this anymore either as it was phased out with the introduction of Docker compatibility. It was easier to justify removing both the Installation system, and the CLI at the time in the interest of an easy docker installation path. It likely wouldn't be a big deal to put a CLI together that is tethered to the backend module. I mention this because it would be a requirement in your proposal if the UI was separated from the core. The frontend in its current iteration post Django removal is being developed using FastAPI which provides api endpoints, and Jinja2 based templating. I haven't done much work on this yet other then setting up a basic template that can be called with parameters to specify what part of the dataset to return & how many results are desired. Turning this into a plugin and decoupling it from the main system could already be accomplished. One does not require the other to run. In fact they are already run in separate threads asynchronously. https://github.com/th3r00t/pyShelf/blob/0.8.0--dev/src/frontend/lib/FastAPIServer.py That being said lacking a CLI based interface to the backend necessitates both to up to do anything other then populate the database with the details of a users ebook library. A plugin system that could override the included Default interface would be one way to accomplish what you are suggesting. This is most likely the best way to accomplish it as well. I see a web based UI as an integral part of the Core program. As far as book scrapers go each one is defined and called via a list of acceptable file extensions. https://github.com/th3r00t/pyShelf/blob/0.8.0--dev/src/backend/lib/library.py Catalogue.process_by_filetype(book_file_by_path) that function is fed by Catalogue.filter_books() which has a regex While I could see a way to make that system into something resembling a plugin system using class overrides comes to mind, I think a better approach taking your technical book with zip file attachments example would be to create a plugin that created its own table in the database and via joined its dataset to particular books in the database by book.id. Deleting a book from the system has not been handled yet other then the previous UI allowing you via Djangos admin panel to remove the entry from the database. I figured outside of that it was acceptable to expect the end user to handle their own filesystem. Again not hard to add the ability to The catalogue is also provided by FastAPI via the html front end, and also via the api endpoints. theming in the ui is SASS based with a compilation step to css each time the server is started. the plugin system would simply have to hook into this step and provide an override SASS document to effectively change the entire theme of the UI. |
Beta Was this translation helpful? Give feedback.
-
with in mind of implementing a mode where everything is a plugins, we should discuss and make decission on the following:
Core Feature:
What is a The core feature, with in mind that pyshelf is a cli, non X ebook manager, i think the core feature that won'T be
"plugin" should be the following
can explain later)
Plugins:
The plugins system will be able to provide extra feature to the core, if everything is a plugins, it's easier to customize, and
have community help by creating only small part of pyshelf, and if something is nice it could be include in the Core plugins
The Plugins will have 2 main type of plugins, the individual plugins ( a single plugins) and the plugins package(a pack of
multiple plugins tied up together to provide special feature all together instead of having to instal multiple single plugins to
get that special thing
Plugins Package: maybe something like a xml or a yaml or anything similar that will provide a list of plugins and version(of
plugins) needed to provide the extra feature. Should individual plugins be packaged with the config file, or should we just
required the individual plugins to be installed??
Individual plugins:
will be usefull for exemple technical ebook (that provide code sample zip so we don'T have to modify our main table
for every ebook type) could have some other feature for manga, comic book or other (maybe some of this feature
could be managed in a pkugins packaged instead of indidivually, maybe having a db_table plugins or something)
individually but only by removing or adding a package
So this is a big brainstorm but if we could established the right direction we (mainly you) want to go, it will be easier to focus on the right part
Beta Was this translation helpful? Give feedback.
All reactions