3 ms·

this made me curious :) do you have some written draft of that idea or need to be asked a series of questions to get it out?

by mr__y 7y ago

dllthomas 7y ago
I've rambled in a few places, but I don't have something collected and coherent. The general principle is exercise of a general push against "the application" as unit of functionality. My main inspiration has been nmh (https://www.nongnu.org/nmh/ https://www.nongnu.org/nmh/). As compared with traditional mail clients, it pushes individual mail-related actions into the shell. The mail client has the advantage of not really needing a long-running process, but that isn't really a blocker - put the functionality behind an API and expose it through utilities, talking to a socket based on shell variables, and you can put together a pretty compelling experience. I wrote a libpurple client that worked that way. Where relevant, you can poll in PROMPT_COMMAND. What does this look like for a web browser? ¯\_(ツ)_/¯ We can mimic a typical web browser experience, with commands to follow links, maybe manage tabs, interact with UX elements, poke the JS on the page? But maybe we could also move away from the sense-of-place metaphor that puts us "on" one page at a time, and fold in stuff learned in spidering? Once we get thinking outside the box, there might be some really interesting things to find. Or maybe not. Please ask any questions you're left with :)
- mr__y 7y ago
  The problem I see is that many websites that rely heavily on JS have become pretty much applications rather than websites and as a result they heavily rely on a long running process. The way I understand this problem, this would rather require a long running browser process and (socket based) API exposed for external commands/apps to work with. But then again this would be not much different than Selenium or the likes. The API could be very different but the general principle (web browser process and an API for external applications to control it) would be the same.
  - dllthomas 7y ago
    Yeah, I think that's about the shape of it. And I think it's something we don't currently have a good, well established pattern for. It calls for something more localized than a daemon, but longer lived than a utility. We see something similar with language servers. In that case (IIUC, and I may not) they're typically tied to specific places in the directory structure (eg. listening on a unix socket created in the root of the relevant source tree). For the chat client I mentioned above, I tied things together with shell and environment variables. The script to start the long-running process read its initial output and set things up so that future commands would know which process to talk to. The code is at https://github.com/dlthomas/genies https://github.com/dlthomas/genies

this made me curious :) do you have some written draft of that idea or need to be asked a series of questions to get it out?

by mr__y 7y ago

this made me curious :) do you have some written draft of that idea or need to be asked a series of questions to get it out?

dllthomas 7y ago

I've rambled in a few places, but I don't have something collected and coherent. The general principle is exercise of a general push against "the application" as unit of functionality. My main inspiration has been nmh (https://www.nongnu.org/nmh/ https://www.nongnu.org/nmh/). As compared with traditional mail clients, it pushes individual mail-related actions into the shell. The mail client has the advantage of not really needing a long-running process, but that isn't really a blocker - put the functionality behind an API and expose it through utilities, talking to a socket based on shell variables, and you can put together a pretty compelling experience. I wrote a libpurple client that worked that way. Where relevant, you can poll in PROMPT_COMMAND. What does this look like for a web browser? ¯\_(ツ)_/¯ We can mimic a typical web browser experience, with commands to follow links, maybe manage tabs, interact with UX elements, poke the JS on the page? But maybe we could also move away from the sense-of-place metaphor that puts us "on" one page at a time, and fold in stuff learned in spidering? Once we get thinking outside the box, there might be some really interesting things to find. Or maybe not. Please ask any questions you're left with :)

mr__y 7y ago
The problem I see is that many websites that rely heavily on JS have become pretty much applications rather than websites and as a result they heavily rely on a long running process. The way I understand this problem, this would rather require a long running browser process and (socket based) API exposed for external commands/apps to work with. But then again this would be not much different than Selenium or the likes. The API could be very different but the general principle (web browser process and an API for external applications to control it) would be the same.
- dllthomas 7y ago
  Yeah, I think that's about the shape of it. And I think it's something we don't currently have a good, well established pattern for. It calls for something more localized than a daemon, but longer lived than a utility. We see something similar with language servers. In that case (IIUC, and I may not) they're typically tied to specific places in the directory structure (eg. listening on a unix socket created in the root of the relevant source tree). For the chat client I mentioned above, I tied things together with shell and environment variables. The script to start the long-running process read its initial output and set things up so that future commands would know which process to talk to. The code is at https://github.com/dlthomas/genies https://github.com/dlthomas/genies