Allow to supply resources about plunker_www HOT 8 OPEN

@iliakan that is a very interesting idea and it also seems to be a elegant way to provide the required functionality behind the scenes. I like that you propose a system in which Plunker does not host the resources (similar to how the package library works).

A challenge that we need to think about is how to integrate this type of functionality into the UI. I don't want to introduce something clunky or unintuitive.

Idea 1

An idea that quickly comes to mind is that upon creating a file, Plunker will identify whether this is a text-based file or not. If the file is not text-based, the user could be prompted to enter a URL at which that resource could be found.

The file would appear in the file listing and clicking on it would simply attempt to embed that file in the main content pane.

Issues:

• Major change to the data structure of plunk / session objects to distinguish in many different places the nature of the file (text vs. binary).
• No easy way to remap files as the rename paradigm wouldn't really fit.

Idea 2

Alternatively, we could create a new multipane (right-hand side) for resource attachments. The UX relating to attaching, removing and remapping could be self-contained in that pane.

Furthermore, this would let the attachments be more easily treated as fundamentally different from files from an internal and back-end perspective.

Challenges

• Integration of new structure into the database and backend api.
• Creation of a protocol for tracking changes to resources between version saves (so that reversion works as expected)
• Modification of the run server to handle pipe / redirect for resources
• Decision of whether or not to display attachments in the embed view or not (probably not)

I would love to hear your thoughts!

from plunker_www.

@ggoodman, cool, let's look into it! ;)

A "resource" is actually a redirect. So we may stop on this term. Regexp-based redirects are more powerful than a simple 1-to-1 mapping.

Implementation (Idea 2)

I believe that the redirect functionality is a logical add-on to a plunk both at the data-level and the UI-level. That's like a RewriteMap for apache (guess you know that old-school server don't you?). Not every plunk needs it and let most users live without knowing about it.

• The multipane (collapsed by default) allows to specify both simple redirects and regexp-based, add/remove them. It also provides a simple way to learn "what is is" with a [?] link.
• The simplest UI to represent redirects would be a kind of a list with [+] [x] and a "regexp" checkbox.
• The server also receives an add-on to handle redirects if supplied.
• Let's not display redirects in the embed view yet. Not sure they are needed there, and it would be an easy thing to add if we see that users want it.

Proxy or 302?

The technical limitation for 302 is that a user will be unable to use redirects for fixing cross-origin issues.

For example, a user may want to make a plunk which demonstrated the use of his remote service. He will not be able to XHR his service without CORS. Also, a user won't be able to include an iframe from his site using a redirected local url, because when browser sees 302, it changes the URL and CORS is applied to the final URL.

So, an <iframe src="service.do"> will actually be not local regarding to CORS if using 302.

A better functionality would be to proxy remote URL through plnkr instead of 302.

While proxying, plunkr will supply X-Forwarded-For and hence it won't be an anonymous proxy. But still it can be used as a free proxy this way. How do you think, would that be dangerous for the service? It seems not, because there are many non-anonymous free proxy servers around, but still it's important to think about possible abuses.

from plunker_www.

Wouldn't it be too hasty from my site to up the issue? :) Just to make sure I get it right about the plans to decline or implement it.

from plunker_www.

Hi @iliakan if you have the time and motivation to do so, I would encourage you 100% to start attacking the issue.

I fully agree with your suggestions but am wary to proxy at the outset. I would prefer to KISS for the time being, see what limitations that approach causes and then adapt after.

Please also note that I'm in the VERY early stages of putting together a rewrite of the editor. This will be happening in the plunker3 branch. I think that the time horizon for the plunker3 project is so long-term that your resource project would be a worthwhile endeavor.

Thanks for your interest!

from plunker_www.

Hello everybody,
have you got any news about this issue?
Thanks,
pietro

from plunker_www.

Plunker.NEXT will allow binary files.

On Sat, Dec 20, 2014, 1:21 PM pietroTP [email protected] wrote:

Hello everybody,
have you got any news about this issue?
Thanks,
pietro

—
Reply to this email directly or view it on GitHub
#8 (comment).

from plunker_www.

how it is going?

from plunker_www.

Is it dead?

from plunker_www.