Rails - Apr 2013 - What are "pages that require authentication" and why they cannot be cached?

I don''t understand what is meant in Rails Guide about caching:
>> Unfortunately, it can''t be applied to every situation
>> (such as pages that need authentication) and since the webserver is
literally
>> just serving a file from the filesystem, cache expiration is an issue
>> that needs to be dealt with.
What are "pages that require authentication"? Are they just the pages
with a form for authentication? Like the main page of facebook.com when
you are not logged in? Then why is it impossible to cache it? It is the
best page for caching because it is always the same, it has only the
html-form. Unlike the profile page that has a lot of fields that are
changed very frequently.

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

On Apr 25, 2013, at 10:37 AM, Wins Lin wrote:
> I don''t understand what is meant in Rails Guide about caching:
> 
>>> Unfortunately, it can''t be applied to every situation
>>> (such as pages that need authentication) and since the webserver is
literally
>>> just serving a file from the filesystem, cache expiration is an
issue
>>> that needs to be dealt with.
> 
> What are "pages that require authentication"? Are they just the
pages
> with a form for authentication? Like the main page of facebook.com when
> you are not logged in? Then why is it impossible to cache it? It is the
> best page for caching because it is always the same, it has only the
> html-form. Unlike the profile page that has a lot of fields that are
> changed very frequently.
No, it would be any page containing unique content meant for that
user''s eyes only. You can''t cache them because they are bound
to the current user''s session -- you can only cache things that are
meant for everyone to see. No filtering or special content-creation can be going
on in any part of cached content. Now you can use what 37Signals refers to as
"Russian Doll" cacheing to cache parts of the page that are held in
common, while letting other parts be dynamically generated. It''s a
yes-and sort of thing. But if you are after a win by caching the entire page,
then it has to be essentially a static page -- same for everyone who views it.

Walter
> 
> -- 
> Posted via http://www.ruby-forum.com/.
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Walter Davis wrote in post #1106898:
> On Apr 25, 2013, at 10:37 AM, Wins Lin wrote:
>
> No, it would be any page containing unique content meant for that
user''s
> eyes only. You can''t cache them because they are bound to the
current
> user''s session -- you can only cache things that are meant for
everyone
> to see. No filtering or special content-creation can be going on in any
> part of cached content. Now you can use what 37Signals refers to as
> "Russian Doll" cacheing to cache parts of the page that are held
in
> common, while letting other parts be dynamically generated. It''s a
> yes-and sort of thing. But if you are after a win by caching the entire
> page, then it has to be essentially a static page -- same for everyone
> who views it.
>
> Walter
Thank you. Now I begin to understand the difference. But then I have
such a question. Why not to cache user''s specific pages? Every
user''s
session has a session_id. So let it be also an id for cached content of
that particular user. Or is it cumbersome for storage to track the 
content for thousand of users?

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Hey have a look on some screencasts on youtube and railscasts:
http://www.youtube.com/watch?v=UnhHZJiSrSc

They''ll completely explain everything you need, rails is able to do
what
you want to do, you just need to learn how to do it.

peace,



On 25 April 2013 16:38, Wins Lin
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> Walter Davis wrote in post #1106898:
> > On Apr 25, 2013, at 10:37 AM, Wins Lin wrote:
> >
> > No, it would be any page containing unique content meant for that
user''s
> > eyes only. You can''t cache them because they are bound to the
current
> > user''s session -- you can only cache things that are meant
for everyone
> > to see. No filtering or special content-creation can be going on in
any
> > part of cached content. Now you can use what 37Signals refers to as
> > "Russian Doll" cacheing to cache parts of the page that are
held in
> > common, while letting other parts be dynamically generated.
It''s a
> > yes-and sort of thing. But if you are after a win by caching the
entire
> > page, then it has to be essentially a static page -- same for everyone
> > who views it.
> >
> > Walter
>
> Thank you. Now I begin to understand the difference. But then I have
> such a question. Why not to cache user''s specific pages? Every
user''s
> session has a session_id. So let it be also an id for cached content of
> that particular user. Or is it cumbersome for storage to track the
> content for thousand of users?
>
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

On Apr 25, 2013, at 11:38 AM, Wins Lin wrote:
> Walter Davis wrote in post #1106898:
>> On Apr 25, 2013, at 10:37 AM, Wins Lin wrote:
>> 
>> No, it would be any page containing unique content meant for that
user''s
>> eyes only. You can''t cache them because they are bound to the
current
>> user''s session -- you can only cache things that are meant for
everyone
>> to see. No filtering or special content-creation can be going on in any
>> part of cached content. Now you can use what 37Signals refers to as
>> "Russian Doll" cacheing to cache parts of the page that are
held in
>> common, while letting other parts be dynamically generated.
It''s a
>> yes-and sort of thing. But if you are after a win by caching the entire
>> page, then it has to be essentially a static page -- same for everyone
>> who views it.
>> 
>> Walter
> 
> Thank you. Now I begin to understand the difference. But then I have
> such a question. Why not to cache user''s specific pages? Every
user''s
> session has a session_id. So let it be also an id for cached content of
> that particular user. Or is it cumbersome for storage to track the 
> content for thousand of users?
You are certainly free to try this out, but I suspect that the trade-off will be
speed of retrieval from storage versus speed of generating the content
dynamically. Yes, I am sure you _can_ do this, but I''m not convinced
you _should_. The reason to cache is to divide the number of visits to an asset
over the lifespan of that asset, and thus distribute the cost of generating it
over a large number of views of the same thing. If you had a "message of
the day", that would definitely benefit from being cached. In the case of a
dynamically-generated page unique to a certain user, that lifespan is usually
the life of the page-view itself, not the application or the day. Your
application is unique, of course, but you should think about the price you would
pay to cache something that will only be viewed once or twice.

Walter

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.