Open machawk1 opened 8 years ago
Irrespective of it being used as a usual web application or natively packaged desktop application, I would prefer keeping the replay and indexer separate from the presentation layer. The server should provide all necessary CORS header to make it accessible from other clients and expose certain headers in order for it to function properly. I would ask @ikreymer to know how mature is JS only rewriting system. If that is reliable and mature enough, then we can rely on client side rewriting completely and keep the server to the minimum.
I would prefer keeping the replay and indexer separate from the presentation layer.
That's the idea. What about something akin to memgator's web interface?
Regarding rewriting, thoughts on using a proxy approach through ipwb's replay script?
That's the idea. What about something akin to memgator's web interface?
That's how I think about it. Provided, there is much more planned on the MemGator's web UI part, independent of the server, all in JS.
Regarding rewriting, thoughts on using a proxy approach through ipwb's replay script?
If JS-only rewriting works reliable enough, we don't have to introduce a proxy, but if needed, a lot of work is already done in pywb that can be leveraged.
Though it's not what I think I intended with this ticket (that being a standalone-ish app), the replay system is aware of the state of the daemon and has toggle capabilities. This comes nowhere close to the mockup and primarily, allowing a user to push/index new WARCs to IPFS using a UI.
https://github.com/ipfs/station recently did integration w/ the daemon using Electron but I have not been able to get it to work from their instructions. Something simple in Electron might be the way to go. Thoughts, @N0taN3rd
@machawk1 I would agree that using Electron for the ui would work great as it has matured a lot since I have started using it. The reason I believe that station did not work is they expect Electron to be installed globally.
A minimal package.json set up derived from WAIL's to get started would be
{
"main": "my-main.js",
"bin": {
"electron": "./node_modules/.bin/electron --js-flags=--harmony"
},
"scripts": {
"run": "electron my-main.js"
},
"devDependencies": {
"electron": "^1.4.11"
}
}
@N0taN3rd That seems to defeat the purpose of Electron -- to have it installed globally for a stand-alone app. I am still deliberating between using a browser-based interface since IPFS already exposes HTTP endpoints, no further dependency baggage would be necessary.
I'll give your config a spin and use it as justification to get more familiar with the Electron ecosystem.
This would allow the app to be a bit more user-friendly. Might include drag-and-drop (+ drop zone) of WARCs, ipfs daemon status (with state toggle), listing of hashed URIs, access to replaying pushed content, etc. Contexts of indexing (CDXJ creation) and replay (enter a hash to pull and replay) can be separate in some context switcher like tabs.
pyinstaller
could be used for natively packaging the code to a .app/binary but as we learned in http://github.com/machawk1/wail , that's a rabbit hole.Alternatively, the main app code could be built w/ pyinstaller then the UI separately in something like Electron. This would allow for the separation of concerns and will allow the ipwb components to work as CLI tools.
See https://app.moqups.com/machawk1/G8aMKa7Cjy/view for a rough mockup.