Cannot get the reason to the plugin being rejected

[tek]

I am posting this critics because I fell hopeless of being replied by any admin here. Sorry if I step on anyone's foot but questionmarks have not to stay in the air, do they?

I received the following e-mail on Jul 31, 2021:

« Your plugin "Cloudinary File Upload v.2.0" has been rejected for the following reason:
This plugin breaks the ProBoards Developer Guidelines. »

When I recieved it, I thought it had some ground for the rejection. Although I quickly checked the guidelines, I couldn't figure out what it could be. Generally speaking, my daily work is very busy and leave everything as it is. But during these last days of the year we are now living, I have had some time to check it back and I really can't find any clue as to which article of the law the plugin ignores.

In our forum, it is working perfect for almost a year. I am not in any quest to become a celebrity as an owner of a plugin used in other forums. I oversatisfied those kind of feelings years ago. But it solves a series of user problems (especially those of non-techy people) introducing the official support of Cloudinary to them.

As a coder since 1986, I am used to be helping people every moment in my day. So would it be something I'm used to when letting people benefit the plugin without even my knowledge becomes possible. However, in return, finding no help on something that contains efforts of numerous days and nights of numerous real persons is no good. While the Cloudinary support team officially tried to help and made me clear at every step and against every user case, option, usage, and risk almost every day for almost a month, the forum members on the other hand helped me during days and nights testing every update and advancement during the coding.

Whenever it comes to my mind and remember the library rejected it, I feel ashamed of the trouble I have created for the people during the time coding it.

OK, I understand the widget being deprecated does not alarm the PB staff but why don't you give a hand to those who try to do something? It's no good...

Furthermore, before submitting the plugin to the library, I asked to be communicated before its being overviewed because there is a need to communicate over it and explain things or ask if a number of plugin functions not mentioned in the guideline do violate anything or not. But no reaction there, either.

Any information would be appreciated.


....


Guidelines:

1. Codes that make requests to ProBoards' servers except through methods explicitly allowed for by ProBoards (such as plugin set() functions). Examples of prohibited codes include using <iframe> tags to access forum content, or making AJAX requests to ProBoards forums.

- It does include NO such content. Neither requests any data from outside the plugin.

2. Codes that affect the placement of advertisements on any ProBoards forum, except those specifically authorized by ProBoards.

- The second guideline is the second clear reason why the plugin complies with the rules. No need to argue.

3. Codes which cause automatic redirects on page load to a new URL.

- There is no redirection throughout the codes. User mouse gestures initiate or stop the plugin process, and that's all.

4. Codes which rely on external code to work properly. Note that using external data is acceptable, so long as that data is loaded asynchronously.

- There is no external code within the plugin. The only two external elements subject to the plugin are the Cloudinary widget which is invoked but not run by the plugin, and a key reader of Ulises's old plugin which is a temporary measure.

5. Codes which use plugin keys to store unrelated data, e.g., sharing a single plugin key between multiple unrelated plugins.

- The plugin stores only one private key which holds user preferences. It is not revealed, nor is mixed with other keys. It doesn't read any other key from any other plugin, at all.

[Chris]

Since this is a most community-driven board and we have no knowledge of the plugin in question and no insight into whatever transpired to get to a "no" in this case, it would probably benefit this thread to be moved to a more visible location where it might get the attention of those involved in the decision or those who can broker the necessary communication to gather an acceptable answer.

I'll tag a few staff members to see if a quick answer is available before moving: Brian Vinh Matej Scott

EDIT:

---

After taking a look at the V2 widget migration it seems quite obvious to me that this would go against rule #4 since it is relying on the external JavaScript code supplied by Cloudinary. I initially assumed it was just a REST API with CORS approved XHR communication between client and server endpoints and think such an API still exists under the surface but the JavaScript code is there adding flourish such as pretty dialogs, drag and drop functionality, XHR communications, etc. The jqueryUI fileupload currently used for the attachment feature could theoretically be repurposed to perform the functions of that external javascript file provided the server endpoints can accept the authentications it can provide.

The basic reasoning behind the restriction against external files is that both the plugin author and Proboards have no control over the resource and could be changed at a whim (internally[disgruntled employee], server pwnage, etc.) to compromise everyone using that plugin across Proboards.

[tek]

Now the case is cleared. Thank you
So, then, there is a market potential on linking forums to hosters which seems to be a big challenge.

Computers exist to serve humans and make life easier so that humankind can get involved producing more value added. When humans repeat steps for stuff that actually computers can automatically do, it is a backward move to the stone age, you know.

In the past, I had to create posts describing how to attach images with every single image hosting service. Then, there were upto 15-20 services actively used. It was those difficult times when I more clearly understood how painful it was to understand all that useless information and discover how to do it for ordinary people. Yes, sometimes we understand with one eye touch, but 90% of the people are not like us. Given all the primitive apps on new devices doing everything even with kids' taps and finger gestures, the bulk ratio of those who cannot even start to understand the stuff within that percentage is rather increasing instead of decreasing. In other words, the carbon black in the milk is even getting more thick.

I'd like to encourage the PB staff to construct a secure way to accomplish such a widget -secure for all sides. Okay, there are more exciting coding projects and advanced technology challenges at the desk. But there are still many undone tasks left behind in the old technologies, as well. Who knows, completing such tasks could make the future more exciting and provide competitive advantages. Actually, it is a duty.

Have good holidays everywhere on the globe