Re: Camping's URL mapping system
Am 13.04.2012 17:40, schrieb Jenna Fox: An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi A4 is about 21*30 cm², i.e. 630 cm² or 97.65 sqin. 300 dpi means 90,000 dpsqin or about 8.788 MdpA4. Without accounting for encoding, redundancy, synchronization etc, this is about 1.1 MByte/A4 paper. If you count both sides → 2.2 MBytes raw data. :) – Matthias ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
LOL! Good to know, if I ever need to do those things :-) An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi On the other hand, Camping is already far too big to fit entirely in a QR code. It would take as many as TWO QR codes to store camping in it's entirety. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
rack has a minimal file-server [0] 0. https://github.com/rack/rack/blob/6496241b25daa20fd9dd736119dc39bdac54869d/lib/rack/file.rb#L70 ive been usin it on my phone to do the basics, it kind of chokes on 128M podcasts as a mediaplayer http://repo.or.cz/w/element.git/blob_plain/HEAD:/doc/find.html it gets the job done though ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi — Jenna On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt dever...@innotts.co.uk skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. Get the best selection of online sites here. Click Here to check them out! http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
On the other hand, Camping is already far too big to fit entirely in a QR code. It would take as many as TWO QR codes to store camping in it's entirety. — Jenna On Saturday, 14 April 2012 at 1:40 AM, Jenna Fox wrote: An A4 piece of paper has a little over 9kb of data storage if storing in binary at 300dpi — Jenna On Saturday, 14 April 2012 at 1:09 AM, Dave Everitt wrote: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
For me, this also depends on what Magnus - as the main Camper ninja - thinks - DaveE I agree, I'd like to see the way Camping works to grow in to something much more usable. Perhaps a fork is a good idea because the legacy would remain and all. But then in the fork we could deal with things that might be kind of annoying at times. And grow it with a steady pace. If we'd fork camping I think we should still stay as minimalistic as possible. Only adding the best things. And work on making it easy to extend. Cheers! Isak Andersson Dave Everitt dever...@innotts.co.uk skrev: There's a crucial point here... if 3k (the old 4k) is a 'proof of concept' and a great exercise in programming skill, it isn't something that most users will really worry about. If the 3k limit has to be broken back up to 4 or even 5k to get some added/altered/ optional functionality that would help usability for the rest of us, it's not an issue for me - DaveE 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
The problem is basically this: Sometimes you want to reference static files, and other components of your site. I have a Gallery app mounted at http://creativepony.com/gallery/ and it causes me all sorts of trouble. Often times to reference static files I end up needing to use /../ in URLs inside of views and controllers, which webservers surprisingly correctly translate in to the wanted files, most of the time. Other times I want to reference other camping apps mounted in the same server instance via a rack URLMap. I know as I say this someone will paste a function I can redefine with some boggling ultracompressed camping code inside, where every variable is a letter - but I have work arounds which work. The trouble is that hacking about like this just isn't fun. In my opinion Camping needs in it's core static file serving, catchall before/after methods for controllers, and I have no idea how, but we need to fix the insanity which is the (self / arg) thing being applied to all src and href values in markaby templates. It's a great idea and I love it when it works, but it's so often a leaky abstraction for me, and when it leaks, there's no clear solution! — Jenna On Thursday, 12 April 2012 at 11:35 PM, Dave Everitt wrote: In another post, Jenna said: I have some trouble with Camping's URL mapping system - so much so I'm considering sinatra for my next ruby web project I just wanted to know what the trouble was, and if/how it might/could/ can't be addressed, so started a new thread. DaveE ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
On Thu, Apr 12, 2012 at 15:59, Jenna Fox a...@creativepony.com wrote: The problem is basically this: Sometimes you want to reference static files, and other components of your site. I have a Gallery app mounted at http://creativepony.com/gallery/ and it causes me all sorts of trouble. Often times to reference static files I end up needing to use /../ in URLs inside of views and controllers, which webservers surprisingly correctly translate in to the wanted files, most of the time. Other times I want to reference other camping apps mounted in the same server instance via a rack URLMap. I know as I say this someone will paste a function I can redefine with some boggling ultracompressed camping code inside, where every variable is a letter - but I have work arounds which work. The trouble is that hacking about like this just isn't fun. In my opinion Camping needs in it's core static file serving bin/camping should serve public/ , catchall before/after methods for controllers, module App def service(*) p :before super ensure p :after end end and I have no idea how, but we need to fix the insanity which is the (self / arg) thing being applied to all src and href values in markaby templates. It's a great idea and I love it when it works, but it's so often a leaky abstraction for me, and when it leaks, there's no clear solution! I agree, although I don't have any elegant solutions… ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping's URL mapping system
bin/camping is great but it's not usually a good way to deploy an app on a server - it tends to be more for development. Putting functionality in to bin/camping which belongs in camping core is like wearing a backpack filled with hydrogen while having your weight checked. 3kb is great and all, but it seems kind of dishonest if the framework isn't even really usable without a bunch of other gems and files and stuff. The conflict between 3/4kb and having robust well designed features often seems to haunt this project. Maybe time for a forking? I have next to no interest in 3kb as a real feature. I think we should have a little line you write right in to your app file which says where you keep your files. Something like MyApp.files = 'public'. Maybe that's the default. 'just redefine service' isn't a good solution no matter how many times you post it on this list. I shouldn't need to lookup any references or archaic mailing list archives to do something so simple in a new project. For the local file urls thing, I propose a breaking change (eg: camping 3.0) the addition of a method named local() # for now it looks like this: def local arg self / arg end and the removal of magic (self / arg)ification of href and src attributes in markaby templates. local() should eventually talk to MyApp.files and the file serving feature so they can all work together nicely - all the code for that should be in one place, maybe in one class. Using local() adds some interesting opportunities too. It'd be really easy to modify local do to other stuff, like load your files from a database, or make urls which reference files by their inode number instead of their file path, or have it return data uris, or have it generate Amazon S3 urls with one time keys in them, or include the file's mtime in the url, allowing the server to specify month-long cache durations while apps instantly pick up changes, making them feel super responsive. One more thought - on file serving, I think it'd be nice if the default was that local files are served out of /files/ url rather than just being at the app's root level. I know this would be controversial: It would be really clear to beginners, and if someone writes img(src: 'files/blah.png') camping can raise a warning explaining the img(src: local 'blah.png') syntax. It also means web servers would need to be explicitly configured to duplicate that behaviour at a lower level - a simple quick camping setup would always serve files through camping, making debugging easier and applications more reliably portable. People who need the performance boost of doing it at the web server level can do that - it just wont happen by default. Deployment is one of the biggest hassles we face - this may help. — Jenna On Friday, 13 April 2012 at 12:26 AM, Magnus Holm wrote: On Thu, Apr 12, 2012 at 15:59, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: The problem is basically this: Sometimes you want to reference static files, and other components of your site. I have a Gallery app mounted at http://creativepony.com/gallery/ and it causes me all sorts of trouble. Often times to reference static files I end up needing to use /../ in URLs inside of views and controllers, which webservers surprisingly correctly translate in to the wanted files, most of the time. Other times I want to reference other camping apps mounted in the same server instance via a rack URLMap. I know as I say this someone will paste a function I can redefine with some boggling ultracompressed camping code inside, where every variable is a letter - but I have work arounds which work. The trouble is that hacking about like this just isn't fun. In my opinion Camping needs in it's core static file serving bin/camping should serve public/ , catchall before/after methods for controllers, module App def service(*) p :before super ensure p :after end end and I have no idea how, but we need to fix the insanity which is the (self / arg) thing being applied to all src and href values in markaby templates. It's a great idea and I love it when it works, but it's so often a leaky abstraction for me, and when it leaks, there's no clear solution! I agree, although I don't have any elegant solutions… ___ Camping-list mailing list Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
