-
Notifications
You must be signed in to change notification settings - Fork 39
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
Discussion: What are the pros/cons of the ipwb web interface acting as a PWA? #734
Comments
The current feature set of IPWB has very little to gain with it being a PWA, though, there is no harm as such. Some selling points of PWAs are listed below:
Our use of ServiceWorker is orthogonal to how it is used in PWAs. |
Thank you for your insights, @ibnesayeed. |
In using more PWAs lately, the native feel in the macOS dock makes me wonder whether it is possible to interact with the icon via drag-and-drop. I am thinking here of adding and/or manipulating the indices and WARCs. The paradigms would be different on different OSes. Per @ibnesayeed and the work for #710, caching for the contents of WACZ files might also be an advantage, as indexing large files with many warc-response records is time consuming (partially due to #631 still being in limbo). |
Progressive Web Apps (PWAs) allow a web site/application to have some representation in the OS outside of the browser with the intention being that they can also work offline to some extent. This might make sense for a locally hosted ipwb instance to visually interface with the local instance.
EDIT: Maybe not as obvious, but from what I can tell, PWAs heavily use Service/WebWorkers, which we already utilize with the Reconstructive integration. Because of this, I would particularly like @ibnesayeed to weigh in.
Re: #26
The text was updated successfully, but these errors were encountered: