user needs to be able to export their data #1

Open
opened 2025-07-06 19:50:43 +00:00 by ferrous_sapling · 0 comments

why we can't get around implementing an "export data" functionality

The most obvious use-case that can't be solved in any other way: user is going to use a different machine, and they won't be in front of their new machine until they are not anymore in front of their old machine. So, the app can't really forward any data on its own/on behalf of the user between the two machines as there is never an opportunity to have a browser running simultaneously on both machines.

While the app does use a bit of server (read: external-to-browser) code and thus tempts us to reuse this server for transferring data between two app "installations", currently the server code exists purely to perform the fetching of feeds whose C.O.R.S. configs don't allow our client (in-browser) code to reach them. Given that this is stateless, let's not start adding state to the server code - especially one that could need to persist for an arbitrary amount of time!

Data that a user could want exported:

  • known feed types
  • known feed urls
  • known feed object tags

Export sequence

  1. User navigates to /export
  2. User clicks on "export data" button
  3. Browser saves exported data to a file (depending on the browser's settings the user might be prompted to give a file name or destination path)

Future enhancement possibilities

  • allow exporting only a subset of all the exportable data. for example, have a list of check-boxes along with a "export all" toggle for ease of use.
  • allow exporting saved feed objects?
## why we can't get around implementing an "export data" functionality The most obvious use-case that can't be solved in any other way: user is going to use a different machine, _and_ they won't be in front of their new machine until they are not anymore in front of their old machine. So, the app can't really forward any data on its own/on behalf of the user between the two machines as there is never an opportunity to have a browser running simultaneously on both machines. While the app _does_ use a bit of server (read: external-to-browser) code and thus tempts us to reuse this server for transferring data between two app "installations", currently the server code exists purely to perform the fetching of feeds whose C.O.R.S. configs don't allow our client (in-browser) code to reach them. Given that this is stateless, let's not start adding state to the server code - especially one that could need to persist for an arbitrary amount of time! ## Data that a user could want exported: - known feed types - known feed urls - known feed object tags ## Export sequence 1. User navigates to `/export` 2. User clicks on "export data" button 3. Browser saves exported data to a file (depending on the browser's settings the user might be prompted to give a file name or destination path) ## Future enhancement possibilities - allow exporting only a subset of all the exportable data. for example, have a list of check-boxes along with a "export all" toggle for ease of use. - allow exporting saved feed objects?
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ferrous_sapling/activity-pub-explorer#1
No description provided.