Annoucing memcache-ada 0.1

Annoucing memcache-ada 0.1

[R. Tyler Croy]

I've gone ahead and typed up a page on AdaCommons detailing the project a bit
more:
    <http://adacommons.org/Memcache>

This release of memcache-ada is the first every release of anything I've ever
written in Ada, so be gentle :)

The full listing of the supported calls can be found on the above wiki page.


Downloads:
    .zip: <https://github.com/rtyler/memcache-ada/zipball/0.1>
    .tar.gz: <https://github.com/rtyler/memcache-ada/tarball/0.1>

Source:
    git: <git://github.com/rtyler/memcache-ada.git>


I hope somebody finds it useful, can't wait to see some examples of caching
with AWS! :D

Cheers
-- 
- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler

Re: Annoucing memcache-ada 0.1

[Maciej Sobczak]

On Jan 16, 9:52 pm, "R. Tyler Croy" <ty...@linux.com> wrote:

> I hope somebody finds it useful, can't wait to see some examples of caching
> with AWS! :D

The biggest advantage of AWS, when compared to "traditional" web-
server hosting stateless scripts, is that AWS is stateful and being an
in-process part of the complete application makes out-of-process
caching useless.
In other words, with AWS there is no need to cache anything in a
separate process, because data can be stored for future use as a
regular object in the program. This is not just faster, but also
safer.

I have to admit, however, that web technologies are not my strongest
point and I might miss some interesting use cases.

--
Maciej Sobczak * http://www.inspirel.com

Re: Annoucing memcache-ada 0.1

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 23:09:32 +0100, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:

> On Jan 16, 9:52 pm, "R. Tyler Croy" <ty...@linux.com> wrote:
>
>> I hope somebody finds it useful, can't wait to see some examples of  
>> caching
>> with AWS! :D
>
> The biggest advantage of AWS, when compared to "traditional" web-
> server hosting stateless scripts, is that AWS is stateful and being an
> in-process part of the complete application makes out-of-process
> caching useless.
> In other words, with AWS there is no need to cache anything in a
> separate process, because data can be stored for future use as a
> regular object in the program. This is not just faster, but also
> safer.
>
> I have to admit, however, that web technologies are not my strongest
> point and I might miss some interesting use cases.
You indeed at least missed an important point : there is *never* something  
like stateful with web process. This is a fundamental consequence of the  
client browsing process. “Stateful web server” concept makes no sense. As  
the user can go back and forward in his/her navigation history, the only  
possible state must be stored in pages stored in the browser, and if ever  
needed, these states informations must be transmitted to the web server  
via POST (preferably, personal feeling). In the web, there is a per-page  
state at the client side, not a per-cession state at the server side.

Of course, many do this error to see state at the server side (and you end  
up with errors and unexpected behaviors from the client point of view).

To talk about caching now, it may take place in so much multiple place  
that there may not be single simple answer. Anyway, caching is in way  
related to a kind of server state. Then, caching applied to static content  
is not the same as caching applied to dynamically generated content. The  
first may be handled by the underlying OS as much as by the server, and  
the second may be as much handled by the client application as much as by  
the server too.

This is not as simply a part of the server solely. This is likely to be  
indeed the topic of a separate process in many cases.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Annoucing memcache-ada 0.1

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 23:41:44 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Anyway, caching is in way related […]

Sorry, I forget a word which change the meaning. Please read “Anyway,  
caching is in no way related […]”

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Annoucing memcache-ada 0.1

[R. Tyler Croy]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:
> On Jan 16, 9:52 pm, "R. Tyler Croy" <ty...@linux.com> wrote:
> 
>> I hope somebody finds it useful, can't wait to see some examples of caching
>> with AWS! :D
> 
> The biggest advantage of AWS, when compared to "traditional" web-
> server hosting stateless scripts, is that AWS is stateful and being an
> in-process part of the complete application makes out-of-process
> caching useless.
> In other words, with AWS there is no need to cache anything in a
> separate process, because data can be stored for future use as a
> regular object in the program. This is not just faster, but also
> safer.
> 
> I have to admit, however, that web technologies are not my strongest
> point and I might miss some interesting use cases.

Heh, that's fine, lucky for you my whole job is in web technologies ;)

Anyways, the big advantages I can see with coupling AWS with memcached by way of
memcache-ada are:

    * Scaling to N web servers serving dynamic content, using a network-attached
      cache such as memcached, you could have web01 do the heavy lifting generating a
      page and then all the other webs (web02 - web05 for example) serve the cached
      version of the page. This can be accomplished via other means via Nginx or
      Varnish (for example), but neither of those will be able to cache arbitrary
      chunks of computed data, merely the responses

    * Providing an intermediary layer to your backing data store (MySQL, PostgreSQL,
      etc). While each RDMS has some amount of in-process caching, it can't really
      compare to the ability to continually add memcached instances. We use
      ~64GB of memcached storage at $WORKPLACE for caching various bits of data here
      and there, this is at the low-end for most big web companies. Indexes can only
      go so far, you can get a lot of mileage out of cheap caching of results from
      your DB.

I'm not sure what AWS is capable of in terms of the Distributed Systems Annex,
but I've never found a web project that couldn't be improved by a little extra
caching here and there :)


Cheers

-- 
- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler

Re: Annoucing memcache-ada 0.1

[Georg Bauhaus]

On 1/16/11 11:09 PM, Maciej Sobczak wrote:

> I have to admit, however, that web technologies are not my strongest
> point and I might miss some interesting use cases.

One interesting use case follows from memcached being a distributed
cache.  (As was asked mentioned, AWS could be distributed via Ada.
Maybe the approaches can be combined?)

Re: Annoucing memcache-ada 0.1

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

>                                                 there is *never*
> something like stateful with web process. This is a fundamental
> consequence of the  client browsing process. “Stateful web server”
> concept makes no sense. As  the user can go back and forward in
> his/her navigation history, the only  possible state must be stored in
> pages stored in the browser, and if ever  needed, these states
> informations must be transmitted to the web server  via POST
> (preferably, personal feeling). In the web, there is a per-page  state
> at the client side, not a per-cession state at the server side.

Using AJAX, there is certainly state within one page... but even
excluding that, there clearly _is_ per-session state on the server; of
course, the browser has to identify the session concerned before the
server can know where to continue from.

Re: Annoucing memcache-ada 0.1

[pascal.obry]

Yannick,

> You indeed at least missed an important point : there is *never* something  
> like stateful with web process. This is a fundamental consequence of the  
> client browsing process. “Stateful web server” concept makes no sense. As  
> the user can go back and forward in his/her navigation history, the only  
> possible state must be stored in pages stored in the browser, and if ever  
> needed, these states informations must be transmitted to the web server  
> via POST (preferably, personal feeling). In the web, there is a per-page  
> state at the client side, not a per-cession state at the server side.

Well yes and no. In AWS the only token sent is a cookie for a per user
state.

We also support per-page state, see Web_Block technology where a MD5
is
auto-magically injected into each page. Basically:

   1. there is a state on the server, user can (via the callback)
update,
      a context object.

   2. when sending the response to the web browser a MD5 of the full
context
      data is created.

   3. this MD5 is automatically injected into the response (HTML, or
XML in
      Ajax XML based response).

It was not easy to get right. I have worked with Olivier Ramonat on
this part
as we wanted to have this kind to context into Vision2Pixels server.
At this
point we think it works just fine and that it is a very cool
technology.

> Of course, many do this error to see state at the server side (and you end  
> up with errors and unexpected behaviors from the client point of view).

I think AWS Web_Block support is immune to that :)

Pascal.

Re: Annoucing memcache-ada 0.1

[Yannick Duchêne (Hibou57)]

Le Mon, 17 Jan 2011 11:50:55 +0100, pascal.obry@gmail.com  
<pascal.obry@gmail.com> a écrit:
> Well yes and no. In AWS the only token sent is a cookie for a per user
> state.
>
> We also support per-page state, see Web_Block technology where a MD5
> is
> auto-magically injected into each page. Basically:
>
>    1. there is a state on the server, user can (via the callback)
> update,
>       a context object.
>
>    2. when sending the response to the web browser a MD5 of the full
> context
>       data is created.
>
>    3. this MD5 is automatically injected into the response (HTML, or
> XML in
>       Ajax XML based response).
This confirm the state has to be hold by the web page, isn't it ?

> I think AWS Web_Block support is immune to that :)
>
> Pascal.
Thanks for the topic, I will probably have a look at it.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Annoucing memcache-ada 0.1

[pascal.obry]

Yannick,

> This confirm the state has to be hold by the web page, isn't it ?

Sure, but only a single token (the key) and no need to use POST as
you said in your previous message. All data are still kept on the
server side.

Pascal.

Re: Annoucing memcache-ada 0.1

[Yannick Duchêne (Hibou57)]

Le Mon, 17 Jan 2011 11:40:12 +0100, Simon Wright <simon@pushface.org> a  
écrit:
> Using AJAX, there is certainly state within one page... but even
> excluding that, there clearly _is_ per-session state on the server; of
> course, the browser has to identify the session concerned before the
> server can know where to continue from.
I see your point, you are right too. I lacked some precision: this depends  
on the involved functionality. If you are serving pages whose access  
requires some right (like browsing a private forum), then it just requires  
a cession state, and the server is able to hold it. On the other hand,  
richer web applications (the ones I was implicitly referring too),  
requires a state stored in the page, or at least a reference to a state  
for that page. If the user hit the Back button, any request made from that  
page will have to send the state associated with that previous page.  
Imagine a user clicking a Submit button in a page retrieved from the  
browser cache he/she reached after hitting Back in the browser; then  
imagine he/she already click this button before he came back to it (this  
is a typical case of error if the server handles the second request with  
the sate associated to the last requested page).

So this depends on what kind of process is involved.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Annoucing memcache-ada 0.1

[Yannick Duchêne (Hibou57)]

Le Mon, 17 Jan 2011 12:02:08 +0100, pascal.obry@gmail.com  
<pascal.obry@gmail.com> a écrit:
> Sure, but only a single token (the key) and no need to use POST as
> you said in your previous message. All data are still kept on the
> server side.
>
> Pascal.
I see, how and within which conditions this way to do is OK. But this may  
be a cause of resources leakage if some conditions are not waranted,  
because how do you (or the server) know resources allocated for a state  
can be released ? The server has no way to know if weither or not this  
state is still associated to a page still opened in one tab of the browser  
or in its cache. Well, I suppose this depends, as with Simon's comment, on  
the kind of functionality being involved (I have the most general case in  
mind).

Or else, may be a cession is allowed to have a single state only, and any  
previous state is made dirty and released.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Annoucing memcache-ada 0.1

[Georg Bauhaus]

On 17.01.11 11:40, Simon Wright wrote:
> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> 
>>                                                 there is *never*
>> something like stateful with web process. [...] state
>> at the client side, not a per-cession state at the server side.
> 
> Using AJAX, there is certainly state within one page... but even
> excluding that, there clearly _is_ per-session state on the server; of
> course, the browser has to identify the session concerned before the
> server can know where to continue from.

Should there be session state in a server at all?  Alternatively,

   State := Server_Side.Evaluate (POST request);

   if Is_Possible_State (State, Web Server Information) then
      ...
   else
      Send_Error_Indication;
   end if;

A request will carry enough information to signal state assumptions.

The gist of it is that there is a finite number of possible states
(and state histories) in a web interaction.  If a request
indicates one of these states (or histories), the server may
continue the interaction.  If possible, it may assume the
corresponding state regardless of actual histories. (Since, in any case
a client may use multiple tabs running the "same" web interaction,
create forged requests, switch computers, exchange cookies,
switch ethernet connections, move VMs, or send request caused
by viral infections ...)

The set of possible states can change while some web interaction
is going on. Model data may have changed in the mean time, since
multiple clients concurrently update data,  effects are as intended
by some request history, etc.
But there always is a set of states, and, therefore, there always
is a predicate to be called for testing a request.

Correct?

Re: Annoucing memcache-ada 0.1

[pascal.obry]

Yannick,

> I see, how and within which conditions this way to do is OK. But this may  
> be a cause of resources leakage if some conditions are not waranted,  
> because how do you (or the server) know resources allocated for a state  
> can be released ?

This is indeed a delicate problem. With AWS there is a time out
associated with
a context. It is released automatically by a running task when the
timeout is
reached.

Note that all this (context creation, injection into HTML or XML,
deletion after
time out...) is transparent to users. At the user level a context is
key/value
table with AWS.

Pascal.

Re: Annoucing memcache-ada 0.1

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Mon, 17 Jan 2011 11:40:12 +0100, Simon Wright <simon@pushface.org>
> a écrit:
>> Using AJAX, there is certainly state within one page... but even
>> excluding that, there clearly _is_ per-session state on the server; of
>> course, the browser has to identify the session concerned before the
>> server can know where to continue from.
>
> I see your point, you are right too. I lacked some precision: this
> depends on the involved functionality. If you are serving pages whose
> access  requires some right (like browsing a private forum), then it
> just requires  a cession state, and the server is able to hold it. On
> the other hand,  richer web applications (the ones I was implicitly
> referring too),  requires a state stored in the page, or at least a
> reference to a state  for that page. If the user hit the Back button,
> any request made from that  page will have to send the state
> associated with that previous page.  Imagine a user clicking a Submit
> button in a page retrieved from the  browser cache he/she reached
> after hitting Back in the browser; then  imagine he/she already click
> this button before he came back to it (this  is a typical case of
> error if the server handles the second request with  the sate
> associated to the last requested page).

Yes, this is a real problem with AJAX applications; you press Back and
end up in something you'd forgotten about half an hour ago. And Forward
will not recover.

Re: Annoucing memcache-ada 0.1

[Simon Wright]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Correct?

Tyler knows much much more about this than I do!