Issues-translate-bot
commented
11 months ago Issue is not in English. It has been translated automatically.
Title: I hope to add a direct transmission method of pictures via WEB, change the logic of comments, and change the logic of splicing suffixes and suffixes of pictures.
Is your feature request related to a problem?
- The picture transmission is slow now. I hope to add a WEB direct transmission method for pictures.
- Now the comment is also a memo, so when using the API to obtain the memo data, it is necessary to judge the parent to distinguish it. I hope the comment logic can be reconsidered.
- After the stored prefix and suffix are set, they are directly spliced into the external_link field, which makes it very inconvenient to use. We hope that the splicing function logic can be reconsidered.
Describe the solution you'd like
-
Looking forward to direct transmission (very much looking forward to it): Now the logic of image transmission is to be transferred through the server, and the bandwidth directly limits the image transmission speed. Domestic machine bandwidth is the most expensive. Generally, the bandwidth of the machine deploying memos is around 3Mbps. It takes too long to transmit the image data stream from the local to the server. It takes double or even more time to transfer from server to cloud storage. It is recommended to refer to the Web direct transmission methods of Alibaba OSS and Tencent COS. Reference: [OSS Web Direct Transmission Best Practices] (https://help.aliyun. com/zh/oss/use-cases/use-postobject-to-upload-objects-by-using-web-clients?spm=5176.8465980.top-nav.5.4e70145072E7nU&scm=20140722.S_help%40%40%E6%96 %87%E6%A1%A3%40%4031923.S_RQW%40ag0%2BBB2%40ag0%2BBB1%40ag0%2Bhot%2Bos0.ID_31923-RL_web%E7%9B%B4%E4%BC%A0-LOC_console~UND~help -OR_ser-V_3-P0_0)
-
Looking forward to redesigning the comment logic: Because the front-end interface design of memos itself is not suitable for many scenarios, and there are many areas where the experience can be improved, more people now use API methods to obtain data and render it into HTML pages designed by themselves, but now the comment function is launched Later, many people's pages inexplicably displayed the comment data as a memo. After checking the database, it was found that the original comment of a memo was also a memo, tied through an association relationship. It was very confusing why the logic of the comments was designed in this way. People did not We don’t expect comments and memos to have a horizontal relationship. More importantly, does such a design violate the database design paradigm? I'm not sure, but I still hope that the boss can reconsider whether it is necessary to change the design.
-
Expect the image suffix and suffix to be written in external_link without splicing: In the current storage settings, you can set the prefix and suffix of the image URL, but the prefix and suffix are finally concatenated with the upload address and written into the external_link field, which leads to several problems: (1) When using multiple domain names at the same time, pictures may be accidentally blocked. (2) When using cloud-stored pictures to dynamically crop, such as Tencent Cloud’s Vientiane function, in memos, both thumbnails and enlarged pictures are added with a crop suffix, which cannot achieve [thumbnail status using the The image address of the suffix. When clicking on the image to enlarge it, use the original image address without the suffix] So consider saving the URL prefix and suffix in the settings in a separate field or json, and dynamically determine whether to append these URL suffixes when displaying the data.
---I am the dividing line of sadness---
I know that open source projects require very careful design, and I also understand the various trade-offs that open source software authors face. The above are just a few of the more painful points during my use. Of course, the most important thing is the first problem of image transmission being transferred through the server too slowly.
Regardless of whether it is adopted or not, I hope all authors will work hard to make memos more easy to use and powerful. Memos is already an indispensable part of my personal Weibo and notes.
Additional context
No response
Irvingouj
byebyehair
github-actions[bot]
期望增加图片WEB直传方式（疯狂期待）
、更改评论的逻辑、更改图片前后缀拼接逻辑为相对地址Is your feature request related to a problem?
1. 现在图片传输慢，希望能够增加图片WEB直传方式
2. 现在评论也是一条memo，导致使用api获取memo数据时还要判断parent来区分，期望评论逻辑是否可以再斟酌3. 现在存储的前缀后缀设置后，直接拼接死在external_link字段里，导致使用非常不便，期望拼接功能逻辑可以再斟酌Describe the solution you'd like
~~2. 期待评论逻辑重新设计： 因为memos本身的前端界面设计适合的场景不多，并且有很多体验可以提升的地方，所以现在更多的人是使用api方式来获取数据，渲染到自己设计的html页面中，但是现在评论功能推出后，很多人页面上突然评论数据也展示成为了一条memos，查看数据库后发现，原来一条memo的评论竟然也是一条memo，通过关联关系捆绑，很不解为何评论的逻辑是这样设计的，人们并不期望评论和memo在是平级关系，更重要的是，这样的设计是否违反了数据库设计范式（一个字段有多重类别含义）？这一点我不太能确定，还是期望大佬能够再斟酌考虑是否有改变设计的必要。~~
~~3. 期待图片前后缀不拼接写死在external_link： 现在的存储设置中，可以设置图片URL的前缀和后缀，但是前缀和后缀最后和上传地址一起拼接写死在了external_link字段中，这导致几个问题： (1)前缀写死的问题：更换图床域名或图床厂商时，除了在数据库执行replace之外无法用其他方式设置，我看有人也提了类似的issue #2419 (2)后缀写死的问题（严重）： 使用云存储的图片动态裁切，例如腾讯云的万象功能可以直接在图片URL后面加参数来放大缩小图片和质量。 如果在memos中添加了URL统一后缀裁切参数[缩小图片质量到15%]，那么在访问memos的时候，所有的图片、包括点击后的放大图，都是15%质量的低质量缩略图片。 而如果不加URL统一裁切参数后缀，那进入memos列表页面会由于大量加载原图而浏览器或手机卡死！ 期望达到【缩略图状态使用带后缀的图片地址，点击图片放大查看时，使用不带后缀的原图地址】，所以是否考虑将设置中的URL前缀后缀使用一个单独的字段或json保存起来，在展示数据的时候，动态的去判断是否要追加这些URL前后缀。~~
------------------我是难过的分界线------------------
我深知开源项目是需要非常谨慎的设计的，也理解开源软件作者各种权衡的不易。 以上只是我在使用过程中比较痛苦的几点，当然最重要的还是第一点图片传输经服务器中转十分缓慢的问题。
无论是否采纳，都期待各位作者加油，能够让memos更加易用和强大，Memos已经是我个人自建微博及笔记，不可或缺的一部分了。
Additional context
No response