This repository has been archived by the owner. It is now read-only.

port to a different web framework #800

Closed
chadwhitacre opened this Issue Mar 26, 2013 · 16 comments

Comments

Projects
None yet
7 participants
@chadwhitacre
Contributor

chadwhitacre commented Mar 26, 2013

Gittip is implemented with the Aspen web framework. We've had a couple conversations on Twitter (latest) about how Gittip would be more accessible to new contributors if it were implemented with a more popular framework, namely Rails or Django.

Now, I wrote Aspen, and I've carried it with me to every job I've had since 2006. Dragged it like a ball and chain or a dog on my ankle is more like it. It's actually been a liability for me, like, I can only really be productive if I'm using Aspen. Call it The Curse of Aspen. :-(

When I came up with the idea for Gittip in 2012, I had had another web app called IHasAMoney that had acquired one user, who was paying me three dollars a month and wasn't even using the product. I think he forgot his password and I hadn't implemented a password reset feature yet. Part of the germ of Gittip was me thinking, "What if enough people gave me three dollars a month that I could just hack on Aspen all day?" Call it the Verizon business plan. (The other side of that was and is, "I would love to just give Guido van Rossum three dollars a month!") The bottom line is that I love Aspen, and I want Gittip to be for Aspen what Basecamp was for Rails and LJW was for Django.

So yeah, Aspen is a liability for Gittip. It's weird and eccentric and off-putting and unconventional. Some people will choose not to contribute to Gittip because of Aspen. But you know what? I'm kind of weird and eccentric and sometimes off-putting, and Gittip itself is rather unconventional. "Aspen seems insane to me," and, "this guy's fucking nuts"—I eat that stuff up. I love those comments!

The good news is that enough people are contributing to Gittip, and enough people who actually use Aspen are having positive experiences with it, that I'm a lot less concerned about it than I was when Gittip launched nine months ago. Aspen has become a part of Gittip's project culture, and it's starting to show signs of taking on a life of its own as well. Heck, since Gittip launched, Aspen has been ported from Python to JavaScript, Go, and Ruby. This might even work! :)

Which is all to say that we're not going to port Gittip away from Aspen while I'm around, and maybe if Gittip is worth hacking on then Aspen is worth hacking with. ;-)

@ehmatthes

This comment has been minimized.

Show comment Hide comment
@ehmatthes

ehmatthes Mar 26, 2013

Was Aspen ported to other languages because people had an academic interest in doing so, or do people have specific projects they want to build using Aspen?

Was Aspen ported to other languages because people had an academic interest in doing so, or do people have specific projects they want to build using Aspen?

@chadwhitacre

This comment has been minimized.

Show comment Hide comment
@chadwhitacre

chadwhitacre Mar 26, 2013

Contributor

@ehmatthes Good question! I kicked off the Ruby and JavaScript ports as exercises to learn Ruby and Node (actually, I did these on-site at my first Ruby and Node meetups). The Ruby port hasn't moved any further than that, but the JS port was since picked up by @geNAZt who took it much further. The Go port was done by @meatballhat (who also started the Python 3 port). I would love to see these used for real projects, of course. I don't know what @geNAZt and @meatballhat have planned. We're planning to use the JavaScript version at least as a dev server for the Gittip widget project (gttp.co).

Contributor

chadwhitacre commented Mar 26, 2013

@ehmatthes Good question! I kicked off the Ruby and JavaScript ports as exercises to learn Ruby and Node (actually, I did these on-site at my first Ruby and Node meetups). The Ruby port hasn't moved any further than that, but the JS port was since picked up by @geNAZt who took it much further. The Go port was done by @meatballhat (who also started the Python 3 port). I would love to see these used for real projects, of course. I don't know what @geNAZt and @meatballhat have planned. We're planning to use the JavaScript version at least as a dev server for the Gittip widget project (gttp.co).

@chadwhitacre

This comment has been minimized.

Show comment Hide comment
@chadwhitacre

chadwhitacre Mar 26, 2013

Contributor

Follow-on blog post that goes into technical detail:

http://whit537.org/2013/03/why-aspen.html

Contributor

chadwhitacre commented Mar 26, 2013

Follow-on blog post that goes into technical detail:

http://whit537.org/2013/03/why-aspen.html

@lyndsysimon

This comment has been minimized.

Show comment Hide comment
@lyndsysimon

lyndsysimon Mar 26, 2013

Contributor

I would be greatly opposed to porting to something monolithic like Django or Rails. If we decided to ever go anywhere, it should be more like Flask, Bottle, or Sinatra.

That said - Aspen just isn't that big. It's not hard to learn, and the documentation is excellent. Further, Gittip is the largest and most active project of which I'm aware on Aspen, and moving it would negatively impact the framework's growth and maturity.

I'm with you here, Chad. Aspen isn't my favorite framework and you know I don't embrace all of its design features, but it's more than adequate for the job.

Finally, Aspen offers an important alternative to the traditional MVC-derived architecture. I would support its continued development and use on Gittip even if I really hated it (which I don't), because I think this sort of diversity in thought is an important contribution to our community.

Contributor

lyndsysimon commented Mar 26, 2013

I would be greatly opposed to porting to something monolithic like Django or Rails. If we decided to ever go anywhere, it should be more like Flask, Bottle, or Sinatra.

That said - Aspen just isn't that big. It's not hard to learn, and the documentation is excellent. Further, Gittip is the largest and most active project of which I'm aware on Aspen, and moving it would negatively impact the framework's growth and maturity.

I'm with you here, Chad. Aspen isn't my favorite framework and you know I don't embrace all of its design features, but it's more than adequate for the job.

Finally, Aspen offers an important alternative to the traditional MVC-derived architecture. I would support its continued development and use on Gittip even if I really hated it (which I don't), because I think this sort of diversity in thought is an important contribution to our community.

@clone1018

This comment has been minimized.

Show comment Hide comment
@clone1018

clone1018 Mar 26, 2013

Contributor

+200 to above

Contributor

clone1018 commented Mar 26, 2013

+200 to above

@dstufft

This comment has been minimized.

Show comment Hide comment
@dstufft

dstufft Mar 26, 2013

I'm pretty sure I've been one of the more vocal folks who've said that personally Aspen is the reason I have not contributed to Gittip. That being said I want to be clear I'm not telling you that you should port away from Aspen, that's a choice for the gittip project to make and not me. I only offer it as a personal data point about what drove me away when I went to go see about doing an informal security minded look around. (Not to say Aspen is wrong, bad, or anything else. Just that I have a lot of things on my plate and while I like the idea behind gittip I don't have the time to learn a one use framework [for me] framework.)

That being said I'm commenting here because Chad doesn't have comments on his blog, and I don't have a blog nor a Hn account and I love discussing tech!

So some thoughts.

  • You mentioned on twitter the "ease of PHP", but it's become increasingly common for PHP applications to have a index.php which uses rewrite rules to dispatch in a way similar to "MVC" frameworks (now almost to the point where the file system based dispatch is very rare). What do you think is different about Aspen that negates the experience of that community where they had this filesystem based routing but developed kludges to work around them?
  • File system based routing makes me very nervous when it comes to allowing users to upload files, how does Aspen protect against me uploading a "simplate" that executes code and having Aspen automatically pick it up as a dispatchable url?
  • How does the "one time run code" and the "run every page load" translate in python import semantics? Are pyc files generated? Is there a global sys.modules like cache?
  • With the implicit context variables how do you handle all of your variables suddenly being viable template values? I can envision accidentally leaking sensitive data through this implicit variable scoping (This especially makes me nervous on a site like Gittip).
  • How do you envision an eco system forming around Aspen? By this I mean Django has reusable apps, Flask has extensions, each of them are ways of bundling reusable functionality up and distributing them. It seems to me by using file system based dispatch you've come back to where PHP is where distributing reusable apps essentially means copying code into your code base.
  • As an extension to the above question, how do you forsee handling overriding templates or wrapping "views"? It appears that the view and template and the url are tightly coupled and it would be difficult for someone to say make a reusable Aspen project and override the templates for their specific instance, or override a particular url for use in this instance.
  • Do you think the ^L character is enough of a delimiter to not get lost between which internal file you're currently using? I noticed in gittip you do a lot of things like: https://github.com/gittip/www.gittip.com/blob/master/www/bank-account.html#L9

And just some general thoughts:

  • Aspen to me feels much more like a Ruby-eqsue convention over configuration with a healthy does of magic sprinkled in versus the explicit is greater than implicitness of Python. This isn't wrong just a comment.
  • Aspen also feels sort of Java centric with "one class per file" ~= "one view per file". Again not wrong, just a comment.

I'm still digesting things so it's likely I'll have more :) I do want to stress though that I'm not arguing to move gittip away from Aspen, just giving my point of view as a potential contributor. In the end it comes down to what you want to optimize, do you want to optimize more people to contribute or if you want to use gittip as a means to further your other project. Neither are wrong :)

dstufft commented Mar 26, 2013

I'm pretty sure I've been one of the more vocal folks who've said that personally Aspen is the reason I have not contributed to Gittip. That being said I want to be clear I'm not telling you that you should port away from Aspen, that's a choice for the gittip project to make and not me. I only offer it as a personal data point about what drove me away when I went to go see about doing an informal security minded look around. (Not to say Aspen is wrong, bad, or anything else. Just that I have a lot of things on my plate and while I like the idea behind gittip I don't have the time to learn a one use framework [for me] framework.)

That being said I'm commenting here because Chad doesn't have comments on his blog, and I don't have a blog nor a Hn account and I love discussing tech!

So some thoughts.

  • You mentioned on twitter the "ease of PHP", but it's become increasingly common for PHP applications to have a index.php which uses rewrite rules to dispatch in a way similar to "MVC" frameworks (now almost to the point where the file system based dispatch is very rare). What do you think is different about Aspen that negates the experience of that community where they had this filesystem based routing but developed kludges to work around them?
  • File system based routing makes me very nervous when it comes to allowing users to upload files, how does Aspen protect against me uploading a "simplate" that executes code and having Aspen automatically pick it up as a dispatchable url?
  • How does the "one time run code" and the "run every page load" translate in python import semantics? Are pyc files generated? Is there a global sys.modules like cache?
  • With the implicit context variables how do you handle all of your variables suddenly being viable template values? I can envision accidentally leaking sensitive data through this implicit variable scoping (This especially makes me nervous on a site like Gittip).
  • How do you envision an eco system forming around Aspen? By this I mean Django has reusable apps, Flask has extensions, each of them are ways of bundling reusable functionality up and distributing them. It seems to me by using file system based dispatch you've come back to where PHP is where distributing reusable apps essentially means copying code into your code base.
  • As an extension to the above question, how do you forsee handling overriding templates or wrapping "views"? It appears that the view and template and the url are tightly coupled and it would be difficult for someone to say make a reusable Aspen project and override the templates for their specific instance, or override a particular url for use in this instance.
  • Do you think the ^L character is enough of a delimiter to not get lost between which internal file you're currently using? I noticed in gittip you do a lot of things like: https://github.com/gittip/www.gittip.com/blob/master/www/bank-account.html#L9

And just some general thoughts:

  • Aspen to me feels much more like a Ruby-eqsue convention over configuration with a healthy does of magic sprinkled in versus the explicit is greater than implicitness of Python. This isn't wrong just a comment.
  • Aspen also feels sort of Java centric with "one class per file" ~= "one view per file". Again not wrong, just a comment.

I'm still digesting things so it's likely I'll have more :) I do want to stress though that I'm not arguing to move gittip away from Aspen, just giving my point of view as a potential contributor. In the end it comes down to what you want to optimize, do you want to optimize more people to contribute or if you want to use gittip as a means to further your other project. Neither are wrong :)

@chadwhitacre

This comment has been minimized.

Show comment Hide comment
@chadwhitacre

chadwhitacre Mar 26, 2013

Contributor

@dstufft This is great feedback, thanks! :D

What do you think is different about Aspen that negates the experience of that community where they had this filesystem based routing but developed kludges to work around them?

I think the difference is that Aspen doesn't let you arbitrarily mix logic and templating.

how does Aspen protect against me uploading a "simplate" that executes code and having Aspen automatically pick it up as a dispatchable url?

Aspen depends on application authors not to write user-uploaded files to locations under the web publishing root.

How does the "one time run code" and the "run every page load" translate in python import semantics? Are pyc files generated? Is there a global sys.modules like cache?

They're exec'd, so there is no pyc file generated, but there is an in-memory cache.

With the implicit context variables how do you handle all of your variables suddenly being viable template values? I can envision accidentally leaking sensitive data through this implicit variable scoping (This especially makes me nervous on a site like Gittip).

I can envision that as well. As with file uploads, Aspen depends on application authors not to screw this up. Are you seeing this as something that site users could influence? Or just application authors?

How do you envision an eco system forming around Aspen?

We're starting to look at using entrypoints for this. E.g.: gittip/aspen-python#150.

It seems to me by using file system based dispatch you've come back to where PHP is where distributing reusable apps essentially means copying code into your code base.

Probably we'd specify the packaging format so that each package includes its own web root, and then we use entrypoints or whatevs to mount those at various locations.

how do you forsee handling overriding templates or wrapping "views"?

This is a function of the templating language, no? Gittip uses Tornado templating, which has bases and includes:

http://aspen.io/simplates/rendered/#extends
http://aspen.io/simplates/rendered/#include

Do you think the ^L character is enough of a delimiter to not get lost between which internal file you're currently using?

For small files it's not a problem, but as you point out, in larger files I do #=================== ^L. That's okay as far as it goes, but for negotiated simplates it doesn't work, and it's a problem there. See https://github.com/gittip/www.gittip.com/blob/master/www/about/stats#L167, where I can't use the comment hack because we're not in a Python syntax page there. We might need to make it \n.*^L.*\n.

Aspen to me feels much more like a Ruby-eqsue convention over configuration with a healthy does of magic sprinkled in versus the explicit is greater than implicitness of Python.

What's the magic? It splits files on ^L and execs. Regex routing is much more magical, imo. :)

Aspen also feels sort of Java centric with "one class per file" ~= "one view per file".

Think of it from the outside in instead of the inside out. The outside world wants HTTP, and doesn't really care about your object model. Aspen works with this HTTP view of the world where servers have resources pointed to by paths.

Contributor

chadwhitacre commented Mar 26, 2013

@dstufft This is great feedback, thanks! :D

What do you think is different about Aspen that negates the experience of that community where they had this filesystem based routing but developed kludges to work around them?

I think the difference is that Aspen doesn't let you arbitrarily mix logic and templating.

how does Aspen protect against me uploading a "simplate" that executes code and having Aspen automatically pick it up as a dispatchable url?

Aspen depends on application authors not to write user-uploaded files to locations under the web publishing root.

How does the "one time run code" and the "run every page load" translate in python import semantics? Are pyc files generated? Is there a global sys.modules like cache?

They're exec'd, so there is no pyc file generated, but there is an in-memory cache.

With the implicit context variables how do you handle all of your variables suddenly being viable template values? I can envision accidentally leaking sensitive data through this implicit variable scoping (This especially makes me nervous on a site like Gittip).

I can envision that as well. As with file uploads, Aspen depends on application authors not to screw this up. Are you seeing this as something that site users could influence? Or just application authors?

How do you envision an eco system forming around Aspen?

We're starting to look at using entrypoints for this. E.g.: gittip/aspen-python#150.

It seems to me by using file system based dispatch you've come back to where PHP is where distributing reusable apps essentially means copying code into your code base.

Probably we'd specify the packaging format so that each package includes its own web root, and then we use entrypoints or whatevs to mount those at various locations.

how do you forsee handling overriding templates or wrapping "views"?

This is a function of the templating language, no? Gittip uses Tornado templating, which has bases and includes:

http://aspen.io/simplates/rendered/#extends
http://aspen.io/simplates/rendered/#include

Do you think the ^L character is enough of a delimiter to not get lost between which internal file you're currently using?

For small files it's not a problem, but as you point out, in larger files I do #=================== ^L. That's okay as far as it goes, but for negotiated simplates it doesn't work, and it's a problem there. See https://github.com/gittip/www.gittip.com/blob/master/www/about/stats#L167, where I can't use the comment hack because we're not in a Python syntax page there. We might need to make it \n.*^L.*\n.

Aspen to me feels much more like a Ruby-eqsue convention over configuration with a healthy does of magic sprinkled in versus the explicit is greater than implicitness of Python.

What's the magic? It splits files on ^L and execs. Regex routing is much more magical, imo. :)

Aspen also feels sort of Java centric with "one class per file" ~= "one view per file".

Think of it from the outside in instead of the inside out. The outside world wants HTTP, and doesn't really care about your object model. Aspen works with this HTTP view of the world where servers have resources pointed to by paths.

@dstufft

This comment has been minimized.

Show comment Hide comment
@dstufft

dstufft Mar 27, 2013

how does Aspen protect against me uploading a "simplate" that executes code and having Aspen automatically pick it up as a dispatchable url?

Aspen depends on application authors not to write user-uploaded files to locations under the web publishing root.

Ok. The main reason I ask is because that used to be a great way to RCE a PHP site :) Gittip doesn't support user uploads as far as I'm aware and Aspen is a niche framework so I don't have a large sampling to see how commonplace it is, but it is an issue that the PHP community has had.

With the implicit context variables how do you handle all of your variables suddenly being viable template values? I can envision accidentally leaking sensitive data through this implicit variable scoping (This especially makes me nervous on a site like Gittip).

I can envision that as well. As with file uploads, Aspen depends on application authors not to screw this up. Are you seeing this as something that site users could influence? Or just application authors?

Application authors. I'm a "professional paranoid" so API's where there is a room for application authors to accidentally expose this kind of information sets off my spidey-sense. Django at one time had a book that suggested passing locals() to templates and it's been considered since a bad idea for basically all these reasons. I would suggest finding a way to make exporting variables an explicit action instead of an implicit action.

It seems to me by using file system based dispatch you've come back to where PHP is where distributing reusable apps essentially means copying code into your code base.

Probably we'd specify the packaging format so that each package includes its own web root, and then we use entrypoints or whatevs to mount those at various locations.

I see, so personally I think having your own homegrown packaging format is a disadvantage (not necessarily a fatal one).

how do you forsee handling overriding templates or wrapping "views"?

This is a function of the templating language, no? Gittip uses Tornado templating, which has bases and includes:

http://aspen.io/simplates/rendered/#extends
http://aspen.io/simplates/rendered/#include

Well specifically I mean I say want to run my own copy of gittip.com. However I want to change the templates around to something that suites me more. In something like Django I would just define another location to locate templates that take precedence over the default ones and define new templates there. It seems with bundling the "view" with the "template" you remove the ability to use the view without using the included template and instead a different one?

The flipside is also true (in a way). You can't reuse a template in another view other than refactoring the template out to it's own file and using include negating the whole concept behind Aspen?

Aspen to me feels much more like a Ruby-eqsue convention over configuration with a healthy does of magic sprinkled in versus the explicit is greater than implicitness of Python.

What's the magic? It splits files on ^L and execs. Regex routing is much more magical, imo. :)

I'm not the worlds biggest fan of regex routing and I don't think it's the ideal solution but it is explicit. Nothing will get routed that isn't defined there. On the contrary using the FS has issues where files get created implicitly (perhaps the file an editor creates when you're sitting in the www root and go vim ../config.py) which can case you to accidently leak information there. That regex mapping has one purpose and the only way something gets added to it is if I very deliberately add it. Programs drop things all over the FS all the time.

Other things like the implicit template scope, changing how aspen treats the file based on a character inside the file, etc.

Again not implicit and "magic" aren't wrong. They aren't my preferred way but many people do like them.

Aspen also feels sort of Java centric with "one class per file" ~= "one view per file".

Think of it from the outside in instead of the inside out. The outside world wants HTTP, and doesn't really care about your object model. Aspen works with this HTTP view of the world where servers have resources pointed to by paths.

You can s/paths/keys/ here and still have an accurate view of HTTP. As far as I can tell there's nothing that ties HTTP to filesystem paths except a (deeply ingrained) convention on using / to create topologies. Other delimiters are perfectly acceptable and just because it happens to share a delimiter with the FS (which stems in large part from history) doesn't mean it's tied to the FS. S3 is fundamentally a key value store and yet it is common to use the / as a delimiter there.

dstufft commented Mar 27, 2013

how does Aspen protect against me uploading a "simplate" that executes code and having Aspen automatically pick it up as a dispatchable url?

Aspen depends on application authors not to write user-uploaded files to locations under the web publishing root.

Ok. The main reason I ask is because that used to be a great way to RCE a PHP site :) Gittip doesn't support user uploads as far as I'm aware and Aspen is a niche framework so I don't have a large sampling to see how commonplace it is, but it is an issue that the PHP community has had.

With the implicit context variables how do you handle all of your variables suddenly being viable template values? I can envision accidentally leaking sensitive data through this implicit variable scoping (This especially makes me nervous on a site like Gittip).

I can envision that as well. As with file uploads, Aspen depends on application authors not to screw this up. Are you seeing this as something that site users could influence? Or just application authors?

Application authors. I'm a "professional paranoid" so API's where there is a room for application authors to accidentally expose this kind of information sets off my spidey-sense. Django at one time had a book that suggested passing locals() to templates and it's been considered since a bad idea for basically all these reasons. I would suggest finding a way to make exporting variables an explicit action instead of an implicit action.

It seems to me by using file system based dispatch you've come back to where PHP is where distributing reusable apps essentially means copying code into your code base.

Probably we'd specify the packaging format so that each package includes its own web root, and then we use entrypoints or whatevs to mount those at various locations.

I see, so personally I think having your own homegrown packaging format is a disadvantage (not necessarily a fatal one).

how do you forsee handling overriding templates or wrapping "views"?

This is a function of the templating language, no? Gittip uses Tornado templating, which has bases and includes:

http://aspen.io/simplates/rendered/#extends
http://aspen.io/simplates/rendered/#include

Well specifically I mean I say want to run my own copy of gittip.com. However I want to change the templates around to something that suites me more. In something like Django I would just define another location to locate templates that take precedence over the default ones and define new templates there. It seems with bundling the "view" with the "template" you remove the ability to use the view without using the included template and instead a different one?

The flipside is also true (in a way). You can't reuse a template in another view other than refactoring the template out to it's own file and using include negating the whole concept behind Aspen?

Aspen to me feels much more like a Ruby-eqsue convention over configuration with a healthy does of magic sprinkled in versus the explicit is greater than implicitness of Python.

What's the magic? It splits files on ^L and execs. Regex routing is much more magical, imo. :)

I'm not the worlds biggest fan of regex routing and I don't think it's the ideal solution but it is explicit. Nothing will get routed that isn't defined there. On the contrary using the FS has issues where files get created implicitly (perhaps the file an editor creates when you're sitting in the www root and go vim ../config.py) which can case you to accidently leak information there. That regex mapping has one purpose and the only way something gets added to it is if I very deliberately add it. Programs drop things all over the FS all the time.

Other things like the implicit template scope, changing how aspen treats the file based on a character inside the file, etc.

Again not implicit and "magic" aren't wrong. They aren't my preferred way but many people do like them.

Aspen also feels sort of Java centric with "one class per file" ~= "one view per file".

Think of it from the outside in instead of the inside out. The outside world wants HTTP, and doesn't really care about your object model. Aspen works with this HTTP view of the world where servers have resources pointed to by paths.

You can s/paths/keys/ here and still have an accurate view of HTTP. As far as I can tell there's nothing that ties HTTP to filesystem paths except a (deeply ingrained) convention on using / to create topologies. Other delimiters are perfectly acceptable and just because it happens to share a delimiter with the FS (which stems in large part from history) doesn't mean it's tied to the FS. S3 is fundamentally a key value store and yet it is common to use the / as a delimiter there.

@pjz

This comment has been minimized.

Show comment Hide comment
@pjz

pjz Mar 27, 2013

Re: "one class per file" ~= 'one view per file", negotiated simplates are totally not that - they're multiple views (dispatched by content-type) of one endpoint. Unless they're wildcard filenamed at which point you can re-do dispatch inside it however you want with the remainder of the path name (that comes in as a variable).

pjz commented Mar 27, 2013

Re: "one class per file" ~= 'one view per file", negotiated simplates are totally not that - they're multiple views (dispatched by content-type) of one endpoint. Unless they're wildcard filenamed at which point you can re-do dispatch inside it however you want with the remainder of the path name (that comes in as a variable).

@chadwhitacre

This comment has been minimized.

Show comment Hide comment
@chadwhitacre

chadwhitacre Mar 27, 2013

Contributor

Ok. The main reason I ask is because that used to be a great way to RCE a PHP site :)

:)

[I]t is an issue that the PHP community has had.

Good look. It seems that an explicit file extension for simplates would mitigate this somewhat. Aspen could provide a helper to be used when storing user-uploaded files on the filesystem, and ensure that they don't have the .spt extension. Eh? Noted on gittip/aspen-python#148.

I would suggest finding a way to make exporting variables an explicit action instead of an implicit action.

Thanks, ticketed: gittip/aspen-python#165

I think having your own homegrown packaging format is a disadvantage.

If there's something out there we can use, I'm up for it.

Well specifically I mean I say want to run my own copy of gittip.com. However I want to change the templates around to something that suites me more. In something like Django I would just define another location to locate templates that take precedence over the default ones and define new templates there. It seems with bundling the "view" with the "template" you remove the ability to use the view without using the included template and instead a different one?

With any significant Aspen app you'll have the template bases that you should be able to override.

Otherwise, the new templates that you define in the Django case—are those built from scratch or copied/pasted from the underlying Django app? In either case you're right, you'd have to do the parallel thing with a whole simplate and not just a template. :shrug:

The flipside is also true (in a way). You can't reuse a template in another view other than refactoring the template out to it's own file and using include negating the whole concept behind Aspen?

Meh, we do this now in Gittip, I don't see it as a big deal: https://github.com/gittip/www.gittip.com/tree/master/templates.

In general I do tend to think of web apps as complete wholes more than assemblages of parts. Maybe Aspen is skewed that way as a result.

On the contrary using the FS has issues where files get created implicitly (perhaps the file an editor creates when you're sitting in the www root and go vim ../config.py) which can case you to accidently leak information there. That regex mapping has one purpose and the only way something gets added to it is if I very deliberately add it. Programs drop things all over the FS all the time.

Hmm ... Brainstorm: In other contexts we've talked about having an in-memory index of the simplates that are on the filesystem. I have an implementation of this on my blog, for example. On startup it walks the tree and stores metadata, which is then used to generate the index on the homepage. I've thought about upstreaming this index and making it more central to Aspen. Perhaps it would be safest to use this index to constrain what files are servable? This would protect against files created while the process was running (presumably the index would reset when the process restarts), and the explicit file extension would add further protection.

Other things like the implicit template scope, changing how aspen treats the file based on a character inside the file

Right, right, ticketed (per above).

As far as I can tell there's nothing that ties HTTP to filesystem paths except a (deeply ingrained) convention on using / to create topologies. Other delimiters are perfectly acceptable and just because it happens to share a delimiter with the FS (which stems in large part from history) doesn't mean it's tied to the FS.

Right. My argument is that fighting against this deeply ingrained, historical-accidental convention is where most of the friction comes from in non-fs-based frameworks. I'm suggesting that the / in HTTP comes directly (historically) from the / in filesystems, and that it's easier to work with that than against it.

Contributor

chadwhitacre commented Mar 27, 2013

Ok. The main reason I ask is because that used to be a great way to RCE a PHP site :)

:)

[I]t is an issue that the PHP community has had.

Good look. It seems that an explicit file extension for simplates would mitigate this somewhat. Aspen could provide a helper to be used when storing user-uploaded files on the filesystem, and ensure that they don't have the .spt extension. Eh? Noted on gittip/aspen-python#148.

I would suggest finding a way to make exporting variables an explicit action instead of an implicit action.

Thanks, ticketed: gittip/aspen-python#165

I think having your own homegrown packaging format is a disadvantage.

If there's something out there we can use, I'm up for it.

Well specifically I mean I say want to run my own copy of gittip.com. However I want to change the templates around to something that suites me more. In something like Django I would just define another location to locate templates that take precedence over the default ones and define new templates there. It seems with bundling the "view" with the "template" you remove the ability to use the view without using the included template and instead a different one?

With any significant Aspen app you'll have the template bases that you should be able to override.

Otherwise, the new templates that you define in the Django case—are those built from scratch or copied/pasted from the underlying Django app? In either case you're right, you'd have to do the parallel thing with a whole simplate and not just a template. :shrug:

The flipside is also true (in a way). You can't reuse a template in another view other than refactoring the template out to it's own file and using include negating the whole concept behind Aspen?

Meh, we do this now in Gittip, I don't see it as a big deal: https://github.com/gittip/www.gittip.com/tree/master/templates.

In general I do tend to think of web apps as complete wholes more than assemblages of parts. Maybe Aspen is skewed that way as a result.

On the contrary using the FS has issues where files get created implicitly (perhaps the file an editor creates when you're sitting in the www root and go vim ../config.py) which can case you to accidently leak information there. That regex mapping has one purpose and the only way something gets added to it is if I very deliberately add it. Programs drop things all over the FS all the time.

Hmm ... Brainstorm: In other contexts we've talked about having an in-memory index of the simplates that are on the filesystem. I have an implementation of this on my blog, for example. On startup it walks the tree and stores metadata, which is then used to generate the index on the homepage. I've thought about upstreaming this index and making it more central to Aspen. Perhaps it would be safest to use this index to constrain what files are servable? This would protect against files created while the process was running (presumably the index would reset when the process restarts), and the explicit file extension would add further protection.

Other things like the implicit template scope, changing how aspen treats the file based on a character inside the file

Right, right, ticketed (per above).

As far as I can tell there's nothing that ties HTTP to filesystem paths except a (deeply ingrained) convention on using / to create topologies. Other delimiters are perfectly acceptable and just because it happens to share a delimiter with the FS (which stems in large part from history) doesn't mean it's tied to the FS.

Right. My argument is that fighting against this deeply ingrained, historical-accidental convention is where most of the friction comes from in non-fs-based frameworks. I'm suggesting that the / in HTTP comes directly (historically) from the / in filesystems, and that it's easier to work with that than against it.

@chadwhitacre

This comment has been minimized.

Show comment Hide comment
@chadwhitacre

chadwhitacre Mar 27, 2013

Contributor

@dstufft Let me be really clear that I love that you're doing this. I'm really happy to have a fresh and paranoid pair of eyes reviewing Aspen. Thank you! :D

Contributor

chadwhitacre commented Mar 27, 2013

@dstufft Let me be really clear that I love that you're doing this. I'm really happy to have a fresh and paranoid pair of eyes reviewing Aspen. Thank you! :D

@pjz

This comment has been minimized.

Show comment Hide comment
@pjz

pjz Mar 27, 2013

As far as I can tell there's nothing that ties HTTP to filesystem paths except a (deeply ingrained) convention on using / to create topologies.

HTTP treats / specially too; relative paths are relative to the path using the / as a separator. Yes, that doesn't mean that HTTP-space has to reflect fs-space, but why not take advantage of the similarity since it's there?

Oh, @dstufft gets my +1 for the paranoid review too!

pjz commented Mar 27, 2013

As far as I can tell there's nothing that ties HTTP to filesystem paths except a (deeply ingrained) convention on using / to create topologies.

HTTP treats / specially too; relative paths are relative to the path using the / as a separator. Yes, that doesn't mean that HTTP-space has to reflect fs-space, but why not take advantage of the similarity since it's there?

Oh, @dstufft gets my +1 for the paranoid review too!

@lyndsysimon

This comment has been minimized.

Show comment Hide comment
@lyndsysimon

lyndsysimon Mar 27, 2013

Contributor

I've nothing concrete to add, but wanted to give @dstufft a 👍.

I've got an idea knocking around about URL parameters being used as an injection vector as/before simplates are rendered, but I don't have a firm enough grasp of how Aspen is handling them to pin down a specific concern yet.

Contributor

lyndsysimon commented Mar 27, 2013

I've nothing concrete to add, but wanted to give @dstufft a 👍.

I've got an idea knocking around about URL parameters being used as an injection vector as/before simplates are rendered, but I don't have a firm enough grasp of how Aspen is handling them to pin down a specific concern yet.

@chadwhitacre

This comment has been minimized.

Show comment Hide comment
@chadwhitacre

chadwhitacre Jul 4, 2013

Contributor

Had another go-round on this, on IRC and Twitter:

https://botbot.me/freenode/gittip/msg/4260130/
https://botbot.me/freenode/gittip/msg/4263990/
https://twitter.com/whit537/status/352739750555291650

Issue is still closed. :-)

Bottom line is that I wouldn't be motivated / productive in another framework, and my productivity still matters at this stage of the game.

Contributor

chadwhitacre commented Jul 4, 2013

Had another go-round on this, on IRC and Twitter:

https://botbot.me/freenode/gittip/msg/4260130/
https://botbot.me/freenode/gittip/msg/4263990/
https://twitter.com/whit537/status/352739750555291650

Issue is still closed. :-)

Bottom line is that I wouldn't be motivated / productive in another framework, and my productivity still matters at this stage of the game.

@meatballhat

This comment has been minimized.

Show comment Hide comment
@meatballhat

meatballhat Jul 4, 2013

The world needs Aspen. 👍

The world needs Aspen. 👍

@chadwhitacre

This comment has been minimized.

Show comment Hide comment
@chadwhitacre

chadwhitacre Apr 23, 2014

Contributor

+1 from @patcon over at gittip#2300 (comment).

Contributor

chadwhitacre commented Apr 23, 2014

+1 from @patcon over at gittip#2300 (comment).

@chadwhitacre chadwhitacre referenced this issue May 23, 2014

Merged

Fix login #2424

@chadwhitacre chadwhitacre referenced this issue in gratipay/inside.gratipay.com Aug 13, 2014

Closed

get a loan #78

@chadwhitacre chadwhitacre referenced this issue Sep 1, 2016

Closed

Bring back takes for Team Gratipay #3994

34 of 34 tasks complete
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.