search

owncloud / ocis

:atom_symbol: ownCloud Infinite Scale Stack
https://doc.owncloud.com/ocis/next/
Apache License 2.0
1.37k stars 180 forks source link

Make space image and readme upload more convinient #8719

Open AlexAndBear opened 6 months ago

AlexAndBear commented 6 months ago

To enhance the efficiency and convenience of managing the .space folder and its associated functionalities, the following improvements are proposed:

  1. Ensure the Persistence of the .space Folder: The .space folder should be inherently integral to the system and therefore should not be subject to deletion unless the entire space or drive itself is deleted. This ensures the stability and consistency of the structure. The same applies to the auto-generated markdown file in the .space folder

  2. Implement Automatic Patching during Upload: Rather than requiring clients to manually patch the drive (specialFolder) after uploading a space image or readme, the server should handle this task automatically. This can be achieved by introducing parameters such as isSpaceReadme=true or isSpaceImage=true during the upload process. By incorporating this functionality into the upload procedure, unnecessary requests are eliminated, streamlining the process for clients and facilitating easier implementation by other clients.

By adopting these enhancements, we not only optimize the management of the .space folder but also improve the overall integration for other clients. These modifications are designed to be non-disruptive, ensuring compatibility with existing systems while offering significant benefits in terms of efficiency and usability.

cc @kulmann @micbar

micbar commented 3 months ago

@AlexAndBear @kobergj

I think you already implemented some improvements. Can this be closed?

AlexAndBear commented 3 months ago

@micbar none of these has been implemented. This is a follow up after the improvements @kobergj did

butonic commented 1 month ago

check if this is better covered with the graph api?

AlexAndBear commented 1 month ago

I think setting isSpaceReadme=true is not necessary anymore, if we disable the ability to delete the .space/readme.md file (which is auto generated, when a space is created).

set isSpaceImage=true is still very welcome

butonic commented 1 month ago

hm ... I wonder if it would be easier to just hardcode the space image path to sth like folder.(png|jpg) / space.(png|jpg). Same goes for the space readme. Wouldn't it make more sense to just always display the content of a Readme.md. Not only in the space root but also in subfolders?

When listing drives in the graph api we can populate the ̀ descriptionandspecial.image` properties if those files are present.

The more I look at the .space folder the more I dislike it ...

why even allow configuring the space image as a property of the space? IMO it should be implicit.

🤔

@tbsbdr @micbar @AlexAndBear do you remember why we added the .space folder?

Wouldn't it be nicer to have a Readme.md and folder.(jpg|png) in every folder?

AlexAndBear commented 1 month ago

In every folder? What's the purpose of this ?

Space readme can an should be hardcoded now. For image: can do that as well but I don't know how you might do this because of the different formats.

butonic commented 1 month ago

So you can give subfolders their own Readme / image. Github also renders the Readme in every directory of a repo.

And on my desktop I can also assign a custom folder icon.

AlexAndBear commented 1 month ago

The .space folder is used to store metadata, such as images and readme files, related to the space.

We introduced this hidden .space folder to protect these files from being accidentally deleted by non-technical users who might not know how to restore or recreate them.

There are some issues with your new approach, particularly with using hardcoded image formats (.png, .bmp, .gif, .jpg, etc.):

If multiple images with the same name but different formats are present, it becomes unclear which image should be displayed. While we could default to a preferred file type, this can be difficult to communicate to users.

The user interface includes a convenient feature that allows users to right-click and set an image as the space image. With the .space folder in use, the selected image is copied to the metadata folder. If we were to use the root folder for this purpose, it could require replacing an existing file, potentially leading to unintended data loss if the previous image is overwritten.

Overall, I really like your idea, but implementing it would represent a significant shift. It would require good communication to the users and involve considerable work on the front end.

We possibly could stop the work on this ticket and do refinements with your idea, if this is something we decide we want to have @tbsbdr I really like @butonic 's approach

2403905 commented 1 month ago

The @butonic 's approach is looking more generic 👍

butonic commented 1 month ago

The .space folder is used to store metadata, such as images and readme files, related to the space.

anything else? the .space folder was originally intended to allow users to sync the image and readme to edit them on their desktop machines, IIRC.

We introduced this hidden .space folder to protect these files from being accidentally deleted by non-technical users who might not know how to restore or recreate them.

They can always be restored from the trash.

However, there are some issues with the current approach, particularly with using hardcoded image formats (.png, .bmp, .gif, .jpg, etc.):

If multiple images with the same name but different formats are present, it becomes unclear which image should be displayed. While we could default to a preferred file type, this can be difficult to communicate to users.

Stick to two formats or just one ... IIRC windows would show folder.jpg as icons ... which seems to be an interesting feature, as as tons of people are complaining if ms tries to ditch it

We would have to document something anyway. The less options we give the easier it is to document and implement.

The user interface includes a convenient feature that allows users to right-click and set an image as the space image. With the .space folder in use, the selected image is copied to the metadata folder. If we were to use the root folder for this purpose, it would require replacing an existing file, potentially leading to unintended data loss if the previous image is overwritten.

Again, we have revisions. Nothing is lost.

AlexAndBear commented 1 month ago

The @butonic 's approach is looking more generic 👍

It is, but it requires some additional work:

  1. Clear communication to users about how to set the image and readme.
  2. A method for choosing which image.x to display when multiple options exist (perhaps based on the last modified date).
  3. Measures to prevent data loss, such as an overwrite confirmation dialog.
  4. Ensuring that the space template is copied to the root folder of the space, rather than the .space folder.
  5. Removing any leftover specialFolder elements in web.
  6. Adjusting code paths to enable displaying images and readme files not just for spaces but also for regular folders in web.
AlexAndBear commented 1 month ago

anything else? the .space folder was originally intended to allow users to sync the image and readme to edit them on their desktop machines, IIRC.

Nothing else, they could still sync it without the folder and as the feature was implemented, we couldn't store the data elsewhere than on the filesystem

Stick to two formats or just one ... IIRC windows would show folder.jpg as icons ... which seems to be an interesting feature, as as tons of people are complaining if ms tries to ditch it

Big no, we can display gif files, that feature is beloved by many

Again, we have revisions. Nothing is lost.

We have, but please try to focus as well on users, that are not that technical versatile