allow access to other files and CGIs on the server

Idea

allow access to other files and CGIs on the server+status

allow access to other files and CGIs on the server+priority

allow access to other files and CGIs on the server+tag

 

allow access to other files and CGIs on the server+issues

If someone wants to shift their site over to Wagn but has existing applications that cannot be handles by Wagn (or files that could be Wagn'd but that they don't want to have to move to make the shift), then we need to provide a way for Wagn to pass through the relevant URLs.

 

allow access to other files and CGIs on the server+solution

Anything in a folder has a slash in the URL. Since we disallow slashes in card names, those could just be passed through.

 

This does not handle URLs of the form wagn.org/foo (say foo is a CGI doing something that Wagn doesn't yet). To handle this we could add a pass-through setting, so if "foo+*self+*pass-through" is yes (it's a Toggle), then Wagn would let wagn.org/foo be handled by the web server. (To edit the foo card you'd have to use wagn.org/card/edit/foo )

 

When we replace plusses with slashes, the pass-through setting could be expanded - instead of being a Toggle it can be "file" or "folder". If foo is set to be a folder, then URLs like wagn.org/foo/app and wagn.org/foo/deep/folders/app all work.

 

To enable Wagn content to be accessed via URLs 'inside' such folders we could implement the file/folder distinction (even before cardnames can have slashes) and then add a *folder setting, such that if "diamond+*self+*folder" Points to "emerald" (and emerald is a *pass-through folder), then wagn.org/emerald/foo is passed through, but wagn.org/emerald/diamond returns the Wagn card "diamond".

 

 

Originally explored on simple url for text pages like css.

 

 


 

I don't know what you mean by a CGI. You mean a script? We already have script cards...

 

I still say if you're interested in translating old urls in some non-wagny format into a wagny one, the answer is to build a translation layer, not to shape wagn's api around directly emulating every extant api out there.

  --Ethan McCutchen.....Wed Jan 19 14:45:35 -0800 2011


Yes, I did mean scripts. But I don't think we want to force everyone to put every script on their site into Wagn. And in any case, they can't be in folders. I'm not proposing, or aware of, any APIs beyond folders (and the special case of scripts at the root) that we need to handle. I s'pose there are sites which do something like wagn.org/?key=variable but I'm happy to wait until someone actually wants to deal with that.

 

Not clear how a translation layer would work - if it seems simpler/better than what I'm proposing, please share more about it?

  --John Abbe.....Wed Jan 19 15:04:35 -0800 2011


The translation layer often happens in apache, but we might be able to make it wagneerable by configuring rails routes. I just means that you can set it up so that x/y/z/foo.html is a recognized pattern that goes to /wagn/foo or whatever.

 

Regardless, I don't think it makes sense to discuss it as a setting, because it happens before you identify a card, not after. We don't want to go through all the process to find and retrieve a card only to ignore it. This is stuff that happens at the parsing stage. The slash in card names, the *folder stuff... that's all later in the process.

 

Is the script thing about stuff in that namespace on the server beforehand? Do you actually have this problem? Can you show it to me?

 

My sense is that's there are rarely tons of scripts in the root folder, and that re-routing can handle everything deeper.

 

I hear that parts of this reflect a user story that you actually have. Can you spell out your problem space? The solutions discussed above seem potentially expensive in developer time, processing, and interface noise. Wondering if we can justify all that.

  --Ethan McCutchen.....Wed Jan 19 17:22:37 -0800 2011


Not understanding your script question "about stuff in the namespace on the server beforehand." I have at least one script in ~/cgi (cgi/pikie) which I would like to keep active.

 

Although the interface I'm offering would be built out of cards, the data from it could be stored in such a way that Wagn checked for matching URLs before retrieving the card. What would the Wagn interface be for setting this up if not via cards?

 

If other geeks like Wagn enough to wish it could handling their website generally this could easily make or break that decision, and while few may have CGIs actually residing in their root directory, my sense is it's not uncommon to have aliases in one's root directory which point to CGIs elsewhere, which obviously Wagn couldn't handle without something like this.

  --John Abbe.....Wed Jan 19 19:25:47 -0800 2011


I suspect this would involve apache configuration, not wagn configuration.

  --Ethan McCutchen.....2013-02-25 00:29:00 +0000


I agree with my year-ago self and am going to close this for now. You can easily configure apache to give the user access to such files so that these requests never go to Wagn at all. Wagn really shouldn't be involved in this.

--Ethan McCutchen.....2014-02-14 16:44:41 +0000

allow access to other files and CGIs on the server+relevant user stories