extensions
extensions copied to clipboard
TurboWarp
Fetch+
The problem with having CORS proxies "built in" to extensions like this is that, the nature of the internet and APIs is that they tend to go offline after an amount of time. We need them to live for as long as TurboWarp theoretically will, and the more we depend on external websites like this, the more projects that might break in the future (projects by real people).
One example is "S-Grab", which is now fundamentally pointless because the API that it relied on appears to be down or dysfunctional.
Providing some kind of direct and more explicit way to tell people about CORS errors (or fetching errors in general) would encourage them to use google and find a CORS proxy of their own - that way if it goes down, TurboWarp isn't to blame.
As always, if a CORS proxy goes down, a fellow TurboWarp user can always swap it out in the source code.
Plus, it's increasingly hard to find a good CORS proxy that's not paid these days.
Even if CORS errors did show up, most users would not know that they need to use a proxy, let alone which one.
In my extension, even if the default proxy doesn't work, you can always use a fallback proxy with the (fetch [x]) block.
On Mon, May 27, 2024, 8:35 PM LilyMakesThings @.***> wrote:
The problem with having CORS proxies "built in" to extensions like this is that, the nature of the internet and APIs is that they tend to go offline after an amount of time. We need them to live for as long as TurboWarp theoretically will, and the more we depend on external websites like this, the more projects that might break in the future (projects by real people).
One example is "S-Grab", which is now fundamentally pointless because the API that it relied on appears to be down or dysfunctional.
Providing some kind of direct and more explicit way to tell people about CORS errors (or fetching errors in general) would encourage them to use google and find a CORS proxy of their own - that way if it goes down, TurboWarp isn't to blame.
— Reply to this email directly, view it on GitHub https://github.com/TurboWarp/extensions/pull/1492#issuecomment-2134174419, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZTWPZKAVJTMWNWPFE4TRRTZEPGNTAVCNFSM6AAAAABIL4DN32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZUGE3TINBRHE . You are receiving this because you authored the thread.Message ID: @.***>
As always, if a CORS proxy goes down, a fellow TurboWarp user can always swap it out in the source code. Plus, it's increasingly hard to find a good CORS proxy that's not paid these days. … --- Even if CORS errors did show up, most users would not know that they need to use a proxy, let alone which one. In my extension, even if the default proxy doesn't work, you can always use a fallback proxy with the (fetch [x]) block.
we should not have to manually update the proxy every time it goes down or stops working, aside from this your pr failed all checks, and goes against many practices, along with fetch and similar extensions to this already existing, which also goes against a guideline, a dedicated extension to just fetch a URL with another service is pointless, as the user themselves should be the one finding and choosing the proxy, not the extension itself.
As always, if a CORS proxy goes down, a fellow TurboWarp user can always swap it out in the source code. Plus, it's increasingly hard to find a good CORS proxy that's not paid these days. … --- Even if CORS errors did show up, most users would not know that they need to use a proxy, let alone which one. In my extension, even if the default proxy doesn't work, you can always use a fallback proxy with the (fetch [x]) block. On Mon, May 27, 2024, 8:35 PM LilyMakesThings @.> wrote: The problem with having CORS proxies "built in" to extensions like this is that, the nature of the internet and APIs is that they tend to go offline after an amount of time. We need them to live for as long as TurboWarp theoretically will, and the more we depend on external websites like this, the more projects that might break in the future (projects by real people). One example is "S-Grab", which is now fundamentally pointless because the API that it relied on appears to be down or dysfunctional. Providing some kind of direct and more explicit way to tell people about CORS errors (or fetching errors in general) would encourage them to use google and find a CORS proxy of their own - that way if it goes down, TurboWarp isn't to blame. — Reply to this email directly, view it on GitHub <#1492 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZTWPZKAVJTMWNWPFE4TRRTZEPGNTAVCNFSM6AAAAABIL4DN32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZUGE3TINBRHE . You are receiving this because you authored the thread.Message ID: _@**.**_>
we should not have to manually update the proxy every time it goes down or stops working,
P.S: your pr failed all checks
I have a problem where I start flame wars easily, so (no offense) I need to stop replying to criticism for a bit.
As always, if a CORS proxy goes down, a fellow TurboWarp user can always swap it out in the source code. Plus, it's increasingly hard to find a good CORS proxy that's not paid these days. … --- Even if CORS errors did show up, most users would not know that they need to use a proxy, let alone which one. In my extension, even if the default proxy doesn't work, you can always use a fallback proxy with the (fetch [x]) block.
I have a problem where I start flame wars easily, so (no offense) I need to stop replying to criticism for a bit.
understandable
As always, if a CORS proxy goes down, a fellow TurboWarp user can always swap it out in the source code.
There are over 100 extensions in this repository that have only 1 consistent maintainer. Reducing the amount of maintenance on each extension is an absolute must, and submitting an entire extension that can only work if it is maintained consistently is simply an unreasonable expectation.
At least if a user of TurboWarp runs into an issue with the CORS proxy they're using in their own code, they can just change it themselves. But what happens when their code suddenly breaks for no apparent reason? Bug reports.
I don't know, this extension just seems like a fundamental nightmare.
Here's my hopefully final argument: the CORS proxy is for convenience, not resilience.
On Tue, May 28, 2024, 9:45 PM LilyMakesThings @.***> wrote:
As always, if a CORS proxy goes down, a fellow TurboWarp user can always swap it out in the source code.
There are over 100 extensions in this repository that have only 1 consistent maintainer. Reducing the amount of maintenance on each extension is an absolute must, and submitting an entire extension that can only work if it is maintained consistently is simply an unreasonable expectation.
At least if a user of TurboWarp runs into an issue with the CORS proxy they're using in their own code, they can just change it themselves. But what happens when their code suddenly breaks for no apparent reason? Bug reports.
I don't know, this extension just seems like a fundamental nightmare.
— Reply to this email directly, view it on GitHub https://github.com/TurboWarp/extensions/pull/1492#issuecomment-2136366982, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZTWPZKFA47ACQ3XCQCVCDDZEUXLLAVCNFSM6AAAAABIL4DN32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGM3DMOJYGI . You are receiving this because you authored the thread.Message ID: @.***>
Here's my hopefully final argument: the CORS proxy is for convenience, not resilience.
Then it's not fit for here, I don't know what to tell you
We do need to properly educate people about CORS and why their fetch blocks usually don't work, that much is true
In addition to concerns listed above, there is another one: a lot of extensions have some kind of "load the thing from URL" blocks, but your current solution only addresses the issue for 1 specific extension.
corsproxy.io is paid, the free version only works up to a certain number of requests and then doesn't let you make any after that
nuh uh
Yes, sorry, that was incorrect. It requires you to create an account at a certain request point, though.
According to the contribution guide, shouldn't this just be an update to the original Fetch extension? The normal fetch mode on this extension is just like the original one but with more boilerplaté and the CORS proxy mode is a copypaste but with a string concatenation slapped in the url field.
According to the contribution guide, shouldn't this just be an update to the original Fetch extension? The normal fetch mode on this extension is just like the original one but with more boilerplaté and the CORS proxy mode is a copypaste but with a string concatenation slapped in the url field.
yes it technically should be an update, but... aside from that the extension is unnecessary so is the modification, to quote garbo:
We do need to properly educate people about CORS and why their fetch blocks usually don't work, that much is true
which does not mean just slapping corsproxy as an option, plus what they said above.
According to the contribution guide, shouldn't this just be an update to the original Fetch extension? The normal fetch mode on this extension is just like the original one but with more boilerplaté and the CORS proxy mode is a copypaste but with a string concatenation slapped in the url field.
yes it technically should be an update, but...
aside from that the extension is unnecessary so is the modification, to quote garbo:
We do need to properly educate people about CORS and why their fetch blocks usually don't work, that much is true
which does not mean just slapping corsproxy as an option, plus what they said above.
It's like making an extension that takes the join block, and making it join a string and "!" to it
This extension shouldn't be merged.
Fetch+is not suitable for the extension. When we seeFetch+we are thinking about fetching streams, submitting forms and more, while the extension is justfetchwith a CORS proxy.corsproxy.iomay monitor and record the requests between the user and the server. It may cause passwords or private information to leak.corsproxy.ioforbids access from some regions including China mainland and Hong Kong, and the extension didn't provide a method to change CORS proxy provider.
I feel like there's still a chance for this extension, despite it's many flaws. For reference, I made a similar PR a while ago (#760) and although it never got merged, some of the fundamental ideas people have brought up in this conversation do carry over from it.
- The extension would need to be more clear about it's use in the title. I agree "Fetch+" sounds a little misleading, and as this extension should act as a tutorial for CORS proxy, having it in the title would help.
- Adding documentation to explain the purpose of CORS proxies and how to use them without the extension would be a necessity. Considering we cannot count on external APIs to be up all the time, and the end goal is to teach people why they need a CORS proxy, having some form of textual explanation to link to would help provide the extension more purpose.
- Perhaps an option to swap CORS proxy providers would be in order. Of course, there's still the chance all are down at once, however it's exponentially smaller, and would be less work to maintain in the event one does permanently shut down.
A more appropriate solution would be to have a better error response for Scratch.fetch from a CORS error. An extension entirely dedicated to just being a CORS proxy is not a solution when it is a fundamentally flawed concept on a number of levels; allowing users to educate themselves on CORS proxies, however...
Just gave it a shot. And I think there are tons of valid points.
But the main one don't hard-code the proxy. You might like a default, but don't lock it in place.
Adding an argument might be a better option.
Also, change the name to something like CORS Fetch which would be less misleading.
Please read the issue I created on this matter, if a maintainer wants to reopen for some purpose please do, but please give and explanation.
This has been closed as in general we don't need a whole extension dedicated to this.. but we also don't need another block that's just a join block added to the fetch extension.
As stated adding all the support to all the extensions that can fetch would be a hassle as well as maintaining the proxy's themselves which is a WHOLE other issue.
