-
Notifications
You must be signed in to change notification settings - Fork 1
An "applications" folder #15
Comments
@pfrazee (nvm, I see you removed that piece of the spec and it was just "site" not "sites") When I was thinking of the sites folder I was just imagining it as personal sites that you were hosting from your dat fs, but the idea of an "applications" and "sites" folder definitely have a lot of overlap. Either way, I think the idea of double-clicking a site "package" and opening files and folders from your fs with them is what excites me here. |
My current thinking is that we're going to incrementally move the user data into their FS. That will mean, for instance, all the dats they've created or are seeding. I'm not sure how, yet -- it may be as objectstore records, or mounts, or both, or something new. Installed apps fall under the same thinking. An apps folder would make a lot of sense as a way to retain the installed apps. (Double clicking them could just take you to the actual dat URL, rather than the mounted URL.) We'll just need to see how the data ecosystem increments and then we'll apply whatever mechanism we chose to the apps. |
@pfrazee reading over this again... even if the user's "preferred" apps aren't represented in the fs, I think the real power that could be enabled here is the ability to "Open..." a file with a web app. I could even see this API existing outside the FS specs. |
Right, the FS element of the applications system is really just an implementation detail. The bigger conversation with apps is what they'll be able to hook into or provide. |
As a possible replacement to the
app://
scheme that you had talked about previously (and a natural follow up to #14), you could have an "applications" folder w/ a bunch of.wapp
packages that are literally just renamed mounts to websites. Double click on them and open up that website. You could then allow users to click files and "Open with.." whatever.wapp
packages they have installed on their dat fs. The app packages could have something akin to a.webmanifest
and indicate their icons, what types of files they can open, and more.update: after thinking through this a bit more, I realized that a mount wouldn't be appropriate, since web apps will need to route based on the dat root. So I guess if you did something like that, these packages would be more-so "anchor links" than they would be "symlinks". I'm also thinking that I may be mis-remembering the purpose of the
app://
scheme and I'm going to try to read up on that again and post some more thoughts at a later time.The text was updated successfully, but these errors were encountered: