On 10/3/07, Orlando Andico <[EMAIL PROTECTED]> wrote: > On 10/3/07, Rogelio Serrano <[EMAIL PROTECTED]> wrote: > .. > > yes thats why in this application i like REST over HTTP. no cookies. > > state and sessions are embedded in uris. > > > > im very sorry for barking up the wrong tree. the problems you confront > > are the problems i avoid. > > > Even if you maintain session state in the URI (something like > cookie-less sessions which are well-known in PHP, JSP, Perl andm > everything else I guess) you still have the problem of replicating > back-end session state (the cookie after all is just an identifier). >
ok the resource is the state. in our http based system the resources are stored in a coda filesystem hosted in 3 servers. well cheap pcs actually but it has not been a problem. im more worried about the switch suddenly dying on us. > Most people use a centralized backing DB to store the session state. > What if that one goes south? > i dont do that but they are screwed. > Memcached is a very good implementation, those guys are much smarter > than me. Hahaha! problem is that it's read-only. Having a writable > global hash space opens up so many cans of worms regarding data > coherency, it's not funny. > > I know of no open-source or Free Software project that handles write > coherency over large clusters efficiently. try gfs2. -- Lay low and nourish in obscurity _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
