packages that contain PC scripts

[raisjn]

talked a little about this idea with eeems:

many remarkable packages are actually pieces of computer software that aren't run on the tablet. for simple enough software, it would be cool if you could plug in your rM tablet and use the software from it (for example: a bash or python script can be run on the host PC but installed on rM)

example ways this could work:

• install restream-pc package
• install a package that turns the rM into a hard drive or a package that sets up a webserver
• PC hits the web URL or mounts the rM's HD with the installed scripts (this mount would only contain PC relevant files and no other files from the rM)

[danshick]

It's a neat idea, but we should think about architecture and operating system differences as well as computer side dependencies. Restream, for example, requires ffmpeg/ffplay, lz4, ssh, and a POSIX environment.

Also, this makes toltec a more interesting target for malware. Probably not a huge concern as the PR process requires review, but we should watch for apps that have binary components, apps that download files, etc.

[matteodelabre]

I share your opinion that having to install things both on the rM and on a PC can be confusing to some users. However, I’m not convinced that this is the best way to solve the problem.

As @danshick mentioned, this would mean that we need to take differences between host systems into account, which would broaden this repo’s scope from supporting a specific embedded system to supporting a whole array of existing systems. We also need to consider that storage is quite scarce on the device.

Another way this could be solved is with a program running on the host system and able to both manage packages on the reMarkable via SSH and install the needed scripts on the host system itself. With this solution, the system differences are handled by this program which is external to the Toltec repo. Maybe this could be handled as part of @Eeems’ Toltec installer? (Not sure if managing opkg packages is in scope for that project.)

[Eeems]

Managing packages isn't currently in scope of the installer, but it doesn't have to remain out of scope.

[LinusCDE]

How about having a package that runs a webserver on the reMarkable?

Like having a package that just shows some "cards" for packages it recognized and are on device with some links.

The package could have the file defining what packages can provide what information on the website in the recipe directory and thus provide a way of other packages editing that.

Quick mockup on how a website might look like:

A file like packages/hostinfoserverwhatever/package_info.yml:

restream: # name of the ipkg package
    display_name: reStream
    description: >-
        In order to stream the framebuffer to your PC, you need the following: ....
        More at: ...

rmservewacominput:
    display_name: rmServeWacomInput
    description: >-
        After you started the script on your reMarkable, use the following script to receive that data on your PC: ...
        More at: ...

This is just a suggestion. I don't intend to do anything in that aspect myself, but having such an info site that has this info might be a nice compromise between maintainability and simplicity.

[danshick]

How about having a package that runs a webserver on the reMarkable?

I've been thinking about this a lot lately for a variety of purposes. Another could be to give apps a convenient way of offering transfer mechanisms for content (that the official webview doesn't support).

You could compile lines-are-rusty for ARM and run it on device and build pdf export without the cloud.

You could allow upload of splash screens and templates.

You could stream the display in-browser.

I wonder if there's a web server (maybe one that can do proxying and static hosting) that's reasonably small and secure that fits the bill. Caddy is nice but possibly overkill. We could use it for toltec specific things but make it extensible for other devs to use as well.

This is definitely out of scope for this issue at this point.

[LinusCDE]

I think we should keep the webservers still seperate for their purposes.

I'm also currently thinking of offering an alternative web ui based on my rmStorageTools which uses rmrl for rendering. That would probably depend on python.

Merging different servers together would probably make a messy mega-server. So having multiple webservers running on some ports seems to be the cleanest to me at this point.

[danshick]

Merging different servers together would probably make a messy mega-server. So having multiple webservers running on some ports seems to be the cleanest to me at this point.

The multiple ports thing is the only part of this that leads me to suggest a consolidated approach. Port 80 is kind of prime real estate for not needing to be specified.

[LinusCDE]

The multiple ports thing is the only part of this that leads me to suggest a consolidated approach. Port 80 is kind of prime real estate for not needing to be specified.

Good point. I didn't plan on using port 80 anyways though. The remarkable web ui already uses it, so I see it as partially claimed or bothersome anyway. No simple web ui should take port 80. They should best choose some alternative port that doesn't clash with any other potential software that might run on the rM.

[danshick]

Good point. I didn't plan on using port 80 anyways though. The remarkable web ui already uses it, so I see it as partially claimed or bothersome anyway. No simple web ui should take port 80. They should best choose some alternative port that doesn't clash with any other potential software that might run on the rM.

Unless you've binary modded xochitl, it only listens on the usb interface. I'd consider port 80 free on wifi, but I'd want a proxying web server listening there so multiple apps could use it (at different subdirectories or dns names or whatever).

Edit: entware actually has nginx and apache, but I'd want to ship a sensible default config for rM.

[raisjn]

How about having a package that runs a webserver on the reMarkable?

I've been thinking about this a lot lately for a variety of purposes. Another could be to give apps a convenient way of offering transfer mechanisms for content (that the official webview doesn't support).

i really like the ideas i'm seeing here. if we have something like linus' proposal for per package data, i would personally store 1) manuals and 2) changelogs. i might also add a small app for reading through manuals on the device proper.