You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directmemory.apache.org by Olivier Lamy <ol...@apache.org> on 2012/02/19 15:23:48 UTC
[DISCUSS] RFC Server implementation
Hello Folks,
I have started to think/hack around having a server implementation to
store object in a direct memory cache (something "à la" memcached).
Before discussing about api (fluent or not) having ugly names for
methods or not ( :P ).
I'd like to share with you my ideas (and get your feedback).
Basically I have something in mind to ease users life:
* retrieve this object with this key (sync and async methods)
* store this object with this key and with this serializer. (sync and
async methods)
* delete an entry (sync and async methods)
The de/serialization is done on client side and exchange are done tru
REST (json) over http(s). (Maybe adding later too a "raw" servlet with
parameters passed as headers)
REST Api ideas.
retrieve object :
GET on ${webPath}/directMemory/retrieve/${key}
return json content if found
{"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
cacheContent is byte[] from serialization.
If no cache entry found for the key, http code returned will be 204
(No Content) but client api will receive a DirectMemoryCacheResponse
object with found field to false.
store object
PUT on ${webPath}/directMemory/store
json content posted
{"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
(serializer is for information and if available on server classLoader
could be use for a toString in the web ui).
delete an entry:
DELETE on ${webPath}/directMemory/delete/${key}
200 if ok, 204 if the key was not found.
Goodies: the webapp will have an ui to display some figures on cache
hit ratio, number of stored elements etc...
Let me know if that makes sense and I can start push some hack :-)
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
PS: FYI, Benoit has proposed a talk with myself to devoxxfr
(http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
We hope to see you there :-).
Re: [DISCUSS] RFC Server implementation
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
+1
is such a pleasure being part of discussions at this level. And +1 also for
devoxx and the request for more information! :)
Ciao,
R
On Sun, Feb 19, 2012 at 10:42 PM, Simone Tripodi
<si...@apache.org>wrote:
> > New/update entry: PUT on ${webPath}/${key} -> body has the object which
> > should be serialized
> > Contains entry: HEAD on ${webPath}/${key} -> 200 / 404
> > Read entry: GET on ${webPath}/${key}
> > Delete entry: DELETE on ${webPath}/${key}
>
> simpler and better, I really like them, good catch Daniel!
> -Simo
>
> PS congrats once again Benoit and Olivier for the great achievement
> and a personal thank you for spreading the voice! Didn't find more
> info on devoxx.fr site, hope to see details soon (j'espere d'avoir la
> possibilité de aller a Paris... :))
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
> New/update entry: PUT on ${webPath}/${key} -> body has the object which
> should be serialized
> Contains entry: HEAD on ${webPath}/${key} -> 200 / 404
> Read entry: GET on ${webPath}/${key}
> Delete entry: DELETE on ${webPath}/${key}
simpler and better, I really like them, good catch Daniel!
-Simo
PS congrats once again Benoit and Olivier for the great achievement
and a personal thank you for spreading the voice! Didn't find more
info on devoxx.fr site, hope to see details soon (j'espere d'avoir la
possibilité de aller a Paris... :))
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
Sorry, my second example is incorrect:
when client request:
+----+
GET ${webPath}/${key}
+----+
the server replies:
+----+
200 OK
Content-Type: application/x-java-serialized-object
serialized body here
+----+
That is how clients understand which type of serialization has been
used to store data.
HTH, bonne journée,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 20, 2012 at 9:31 AM, Simone Tripodi
<si...@apache.org> wrote:
> Bonjour!
>
>> BTW I don't follow/understand you regarding the Content-Type.
>> It's just to say the serializer used ? Because Object to cache must be
>> serialized on client side before going to the server.
>
> we are on the same path, taht is what I meant, I just was too
> "compressed" on exposing my consideration :P
>
> So, just to be more clear through meta-code:
>
> * storing/updating an object would mean the client sends
>
> +----+
> PUT ${webPath}/${key}
> Content-Type: application/x-java-serialized-object
>
> serialized-body
> +----+
>
> the server is able to read the body message via the Content-Type HTTP header;
>
> * getting an object:
>
> +----+
> GET ${webPath}/${key}
> Accept: application/x-java-serialized-object
> +----+
>
> the server streams the body content (if 200) so the client is able to
> understand which is the format of serialization and able to
> deserialize the body stream.
>
> How does it sound?
> A trés bientôt,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Feb 20, 2012 at 12:28 AM, Olivier Lamy <ol...@apache.org> wrote:
>> Agree on suggestion and the raw servlet model.
>
>>
>> 2012/2/19 Daniel Manzke <da...@googlemail.com>:
>>> (after another long discussion with simone ;))
>>>
>>> +1 for the content-type idea. I think there should be a server-side
>>> configuration, where you can map content-type to serializers.
>>>
>>> Like mentioned before, I would add a cache "layer" in the path, so you can
>>> add new caches at runtime. (necessary for cloud env? :))
>> Why not even if the goal was not really to have more than direct
>> memory impl on server side :-)
>>>
>>> BTW: What comes after the cloud? The sky! :P
>>>
>>> New/update entry: PUT on ${webPath}/${key} -> body has the object which
>>> should be serialized
>>> Contains entry: HEAD on ${webPath}/${key} -> 200 / 404
>>> Read entry: GET on ${webPath}/${key}
>>> Delete entry: DELETE on ${webPath}/${key}
>>>
>>> Bye,
>>> Daniel
>>>
>>> 2012/2/19 Simone Tripodi <si...@apache.org>
>>>
>>>> I am +1 for the Olivier's idea - and I can put my hand on fire nobody
>>>> would object it! - anyway at the same time I think Daniel's
>>>> consideration really worth - I have a past of RESTer as well :D - I
>>>> would go for
>>>>
>>>> New entry: POST on ${webPath} -> returns 201 with location
>>>> Read entry: GET on ${webPath}/${key}
>>>> Update entry: PUT on ${webPath}/${key}
>>>> Delete entry: DELETE on ${webPath}/${key}
>>>>
>>>> moreover I'd suggest to avoid managing the stored content in textual
>>>> format (it has a cost!), I would proceed for a pure HTTP Content-Type
>>>> negotiation:
>>>>
>>>> application/x-java-serialized-object ->
>>>> org.apache.directmemory.serialization.StandardSerializer
>>>> application/x-protobuf ->
>>>> org.apache.directmemory.serialization.protobuf.ProtobufSerializer
>>>> ...
>>>> and so on, no real need to jsonize requests/objects, just pure, simple
>>>> HTTP.
>>>>
>>>> +1 for the UI part - actual Archiva UI shows the potentials!
>>>>
>>>> HTH, all the best,
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Sun, Feb 19, 2012 at 8:53 PM, Daniel Manzke
>>>> <da...@googlemail.com> wrote:
>>>> > Hi,
>>>> >
>>>> > I could start a REST war now, but I try to be normal. ;)
>>>> >
>>>> > /{webapp}/directMemory/...
>>>> >
>>>> > Why do you need "directMemory"? Are there any other implementations?
>>>> > "directMemory" can be the webapp name, if you need it, but you should not
>>>> > use it there.
>>>> >
>>>> > Why do you need "/store" to simulate methods? You have all you need in
>>>> http.
>>>> >
>>>> > PUT/POST/DELETE
>>>> >
>>>> > And you are already using it. ;)
>>>> >
>>>> > I would do it like this:
>>>> >
>>>> > New entry: PUT on ${webPath} -> returns 201 with location
>>>> > Read entry: GET on ${webPath}/${key}
>>>> > Update entry: PUT/POST on ${webPath}/${key}
>>>> > Delete entry: DELETE on ${webPath}/${key}
>>>> >
>>>> > If you want some kind of separation because of having a website or
>>>> > something else a name for the resource would be fine. (but I wouldn't
>>>> call
>>>> > it directMemory) Maybe "store" or "cache"?
>>
>> ${contextPath}/cache/etc... ?
>> Yup separation will be needed for ui part.
>>
>> I will try to push some code early this week.
>>
>>>> >
>>>> > Additionally I would add a name for the cache to the api.
>>>> > GET on ${webPath}/${cache}/${key}
>>>> >
>>>> > So you could have multiple caches for different scenarios.
>>>> >
>>>> >
>>>> > Bye,.
>>>> > Daniel
>>>> > 2012/2/19 Olivier Lamy <ol...@apache.org>
>>>> >
>>>> >> Hello Folks,
>>>> >>
>>>> >> I have started to think/hack around having a server implementation to
>>>> >> store object in a direct memory cache (something "à la" memcached).
>>>> >>
>>>> >> Before discussing about api (fluent or not) having ugly names for
>>>> >> methods or not ( :P ).
>>>> >> I'd like to share with you my ideas (and get your feedback).
>>>> >>
>>>> >> Basically I have something in mind to ease users life:
>>>> >> * retrieve this object with this key (sync and async methods)
>>>> >> * store this object with this key and with this serializer. (sync and
>>>> >> async methods)
>>>> >> * delete an entry (sync and async methods)
>>>> >>
>>>> >> The de/serialization is done on client side and exchange are done tru
>>>> >> REST (json) over http(s). (Maybe adding later too a "raw" servlet with
>>>> >> parameters passed as headers)
>>>> >>
>>>> >> REST Api ideas.
>>>> >>
>>>> >> retrieve object :
>>>> >> GET on ${webPath}/directMemory/retrieve/${key}
>>>> >>
>>>> >> return json content if found
>>>> >>
>>>> >> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>>> >>
>>>> >> cacheContent is byte[] from serialization.
>>>> >>
>>>> >> If no cache entry found for the key, http code returned will be 204
>>>> >> (No Content) but client api will receive a DirectMemoryCacheResponse
>>>> >> object with found field to false.
>>>> >>
>>>> >> store object
>>>> >>
>>>> >> PUT on ${webPath}/directMemory/store
>>>> >>
>>>> >> json content posted
>>>> >>
>>>> >>
>>>> >>
>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>> >>
>>>> >> (serializer is for information and if available on server classLoader
>>>> >> could be use for a toString in the web ui).
>>>> >>
>>>> >> delete an entry:
>>>> >>
>>>> >> DELETE on ${webPath}/directMemory/delete/${key}
>>>> >>
>>>> >> 200 if ok, 204 if the key was not found.
>>>> >>
>>>> >> Goodies: the webapp will have an ui to display some figures on cache
>>>> >> hit ratio, number of stored elements etc...
>>>> >>
>>>> >> Let me know if that makes sense and I can start push some hack :-)
>>>> >>
>>>> >> --
>>>> >> Olivier Lamy
>>>> >> Talend: http://coders.talend.com
>>>> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>> >>
>>>> >>
>>>> >> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
>>>> >> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
>>>> >> We hope to see you there :-).
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Viele Grüße/Best Regards
>>>> >
>>>> > Daniel Manzke
>>>>
>>>
>>>
>>>
>>> --
>>> Viele Grüße/Best Regards
>>>
>>> Daniel Manzke
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
Bonjour!
> BTW I don't follow/understand you regarding the Content-Type.
> It's just to say the serializer used ? Because Object to cache must be
> serialized on client side before going to the server.
we are on the same path, taht is what I meant, I just was too
"compressed" on exposing my consideration :P
So, just to be more clear through meta-code:
* storing/updating an object would mean the client sends
+----+
PUT ${webPath}/${key}
Content-Type: application/x-java-serialized-object
serialized-body
+----+
the server is able to read the body message via the Content-Type HTTP header;
* getting an object:
+----+
GET ${webPath}/${key}
Accept: application/x-java-serialized-object
+----+
the server streams the body content (if 200) so the client is able to
understand which is the format of serialization and able to
deserialize the body stream.
How does it sound?
A trés bientôt,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 20, 2012 at 12:28 AM, Olivier Lamy <ol...@apache.org> wrote:
> Agree on suggestion and the raw servlet model.
>
> 2012/2/19 Daniel Manzke <da...@googlemail.com>:
>> (after another long discussion with simone ;))
>>
>> +1 for the content-type idea. I think there should be a server-side
>> configuration, where you can map content-type to serializers.
>>
>> Like mentioned before, I would add a cache "layer" in the path, so you can
>> add new caches at runtime. (necessary for cloud env? :))
> Why not even if the goal was not really to have more than direct
> memory impl on server side :-)
>>
>> BTW: What comes after the cloud? The sky! :P
>>
>> New/update entry: PUT on ${webPath}/${key} -> body has the object which
>> should be serialized
>> Contains entry: HEAD on ${webPath}/${key} -> 200 / 404
>> Read entry: GET on ${webPath}/${key}
>> Delete entry: DELETE on ${webPath}/${key}
>>
>> Bye,
>> Daniel
>>
>> 2012/2/19 Simone Tripodi <si...@apache.org>
>>
>>> I am +1 for the Olivier's idea - and I can put my hand on fire nobody
>>> would object it! - anyway at the same time I think Daniel's
>>> consideration really worth - I have a past of RESTer as well :D - I
>>> would go for
>>>
>>> New entry: POST on ${webPath} -> returns 201 with location
>>> Read entry: GET on ${webPath}/${key}
>>> Update entry: PUT on ${webPath}/${key}
>>> Delete entry: DELETE on ${webPath}/${key}
>>>
>>> moreover I'd suggest to avoid managing the stored content in textual
>>> format (it has a cost!), I would proceed for a pure HTTP Content-Type
>>> negotiation:
>>>
>>> application/x-java-serialized-object ->
>>> org.apache.directmemory.serialization.StandardSerializer
>>> application/x-protobuf ->
>>> org.apache.directmemory.serialization.protobuf.ProtobufSerializer
>>> ...
>>> and so on, no real need to jsonize requests/objects, just pure, simple
>>> HTTP.
>>>
>>> +1 for the UI part - actual Archiva UI shows the potentials!
>>>
>>> HTH, all the best,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sun, Feb 19, 2012 at 8:53 PM, Daniel Manzke
>>> <da...@googlemail.com> wrote:
>>> > Hi,
>>> >
>>> > I could start a REST war now, but I try to be normal. ;)
>>> >
>>> > /{webapp}/directMemory/...
>>> >
>>> > Why do you need "directMemory"? Are there any other implementations?
>>> > "directMemory" can be the webapp name, if you need it, but you should not
>>> > use it there.
>>> >
>>> > Why do you need "/store" to simulate methods? You have all you need in
>>> http.
>>> >
>>> > PUT/POST/DELETE
>>> >
>>> > And you are already using it. ;)
>>> >
>>> > I would do it like this:
>>> >
>>> > New entry: PUT on ${webPath} -> returns 201 with location
>>> > Read entry: GET on ${webPath}/${key}
>>> > Update entry: PUT/POST on ${webPath}/${key}
>>> > Delete entry: DELETE on ${webPath}/${key}
>>> >
>>> > If you want some kind of separation because of having a website or
>>> > something else a name for the resource would be fine. (but I wouldn't
>>> call
>>> > it directMemory) Maybe "store" or "cache"?
>
> ${contextPath}/cache/etc... ?
> Yup separation will be needed for ui part.
>
> I will try to push some code early this week.
>
>>> >
>>> > Additionally I would add a name for the cache to the api.
>>> > GET on ${webPath}/${cache}/${key}
>>> >
>>> > So you could have multiple caches for different scenarios.
>>> >
>>> >
>>> > Bye,.
>>> > Daniel
>>> > 2012/2/19 Olivier Lamy <ol...@apache.org>
>>> >
>>> >> Hello Folks,
>>> >>
>>> >> I have started to think/hack around having a server implementation to
>>> >> store object in a direct memory cache (something "à la" memcached).
>>> >>
>>> >> Before discussing about api (fluent or not) having ugly names for
>>> >> methods or not ( :P ).
>>> >> I'd like to share with you my ideas (and get your feedback).
>>> >>
>>> >> Basically I have something in mind to ease users life:
>>> >> * retrieve this object with this key (sync and async methods)
>>> >> * store this object with this key and with this serializer. (sync and
>>> >> async methods)
>>> >> * delete an entry (sync and async methods)
>>> >>
>>> >> The de/serialization is done on client side and exchange are done tru
>>> >> REST (json) over http(s). (Maybe adding later too a "raw" servlet with
>>> >> parameters passed as headers)
>>> >>
>>> >> REST Api ideas.
>>> >>
>>> >> retrieve object :
>>> >> GET on ${webPath}/directMemory/retrieve/${key}
>>> >>
>>> >> return json content if found
>>> >>
>>> >> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>> >>
>>> >> cacheContent is byte[] from serialization.
>>> >>
>>> >> If no cache entry found for the key, http code returned will be 204
>>> >> (No Content) but client api will receive a DirectMemoryCacheResponse
>>> >> object with found field to false.
>>> >>
>>> >> store object
>>> >>
>>> >> PUT on ${webPath}/directMemory/store
>>> >>
>>> >> json content posted
>>> >>
>>> >>
>>> >>
>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>> >>
>>> >> (serializer is for information and if available on server classLoader
>>> >> could be use for a toString in the web ui).
>>> >>
>>> >> delete an entry:
>>> >>
>>> >> DELETE on ${webPath}/directMemory/delete/${key}
>>> >>
>>> >> 200 if ok, 204 if the key was not found.
>>> >>
>>> >> Goodies: the webapp will have an ui to display some figures on cache
>>> >> hit ratio, number of stored elements etc...
>>> >>
>>> >> Let me know if that makes sense and I can start push some hack :-)
>>> >>
>>> >> --
>>> >> Olivier Lamy
>>> >> Talend: http://coders.talend.com
>>> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>> >>
>>> >>
>>> >> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
>>> >> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
>>> >> We hope to see you there :-).
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Viele Grüße/Best Regards
>>> >
>>> > Daniel Manzke
>>>
>>
>>
>>
>> --
>> Viele Grüße/Best Regards
>>
>> Daniel Manzke
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
Changed a bit.
Check updated doc :-)
2012/2/21 Olivier Lamy <ol...@apache.org>:
> 2012/2/21 Daniel Manzke <da...@googlemail.com>:
>> After a short look at the documentation, I wanted to ask, if the
>> Client-side API should really be so complex? :)
> Agree I will try to simplify with adding/moving some in the configuration bean.
>> For me it is a little bit hard, that for just retrieving a value from my
>> cache:
>>
>> DirectMemoryCacheResponse<Wine> response =
>> client.retrieve(
>> new DirectMemoryCacheRequest().setKey( "bordeaux" )
>> .setSerializer( SerializerFactory.createNewSerializer() )
>> .setExchangeType( ExchangeType.JSON )
>> .setObjectClass( Wine.class ) );
>>
>> I think for the client-side it should be transparent, if you are using a
>> local or a remote cache.
> My goal was to build only an api to ask a remote cache so I preferred
> to start with that only (SOC pattern).
> As we will probably add the "cache region" feature (I will start an
> other thread on that), I think we will need something on top of that
> i.e. something to select (a kind of Factory) the correct CacheService
> instance.
>
> BTW I will add a new parameter cacheRegion in the rq bean to the server.
>
>
>>
>> Means: the complexity should kept from the client. the client should use
>> the CacheService-Interface
>>
>>
>> WDYT? :)
>>
>> (JAX-RS client api? jersey / cxf client api? :))
>>
>> 2012/2/21 Olivier Lamy <ol...@apache.org>
>>
>>> 2012/2/21 Raffaele P. Guidi <ra...@gmail.com>:
>>> > And is there already a schedule? I sometimes hang in paris (my employer
>>> is
>>> > a french bank) and could have some meeting in that period
>>>
>>> AFAIK not yet.
>>>
>>> >
>>> > On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch>
>>> wrote:
>>> >
>>> >> > can you please share more devoxx details please? I could come to
>>> Paris!
>>> >>
>>> >> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
>>> >> of the presentation will be in French.
>>> >>
>>> >> We will present DM under the Tools in Action topic. I still don't know
>>> >> precisely what will be in the presentation, but I will work hard the
>>> >> two next monthes to be able to show something impressive :)
>>> >>
>>> >> For more details (but again, in French) you can check the web site :
>>> >> http://devoxx.fr
>>> >>
>>> >> If some of you plan to come we could try to organize a DM meetup at
>>> >> the same time
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Benoit.
>>> >>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>
>>
>>
>> --
>> Viele Grüße/Best Regards
>>
>> Daniel Manzke
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
2012/2/21 Daniel Manzke <da...@googlemail.com>:
> After a short look at the documentation, I wanted to ask, if the
> Client-side API should really be so complex? :)
Agree I will try to simplify with adding/moving some in the configuration bean.
> For me it is a little bit hard, that for just retrieving a value from my
> cache:
>
> DirectMemoryCacheResponse<Wine> response =
> client.retrieve(
> new DirectMemoryCacheRequest().setKey( "bordeaux" )
> .setSerializer( SerializerFactory.createNewSerializer() )
> .setExchangeType( ExchangeType.JSON )
> .setObjectClass( Wine.class ) );
>
> I think for the client-side it should be transparent, if you are using a
> local or a remote cache.
My goal was to build only an api to ask a remote cache so I preferred
to start with that only (SOC pattern).
As we will probably add the "cache region" feature (I will start an
other thread on that), I think we will need something on top of that
i.e. something to select (a kind of Factory) the correct CacheService
instance.
BTW I will add a new parameter cacheRegion in the rq bean to the server.
>
> Means: the complexity should kept from the client. the client should use
> the CacheService-Interface
>
>
> WDYT? :)
>
> (JAX-RS client api? jersey / cxf client api? :))
>
> 2012/2/21 Olivier Lamy <ol...@apache.org>
>
>> 2012/2/21 Raffaele P. Guidi <ra...@gmail.com>:
>> > And is there already a schedule? I sometimes hang in paris (my employer
>> is
>> > a french bank) and could have some meeting in that period
>>
>> AFAIK not yet.
>>
>> >
>> > On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch>
>> wrote:
>> >
>> >> > can you please share more devoxx details please? I could come to
>> Paris!
>> >>
>> >> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
>> >> of the presentation will be in French.
>> >>
>> >> We will present DM under the Tools in Action topic. I still don't know
>> >> precisely what will be in the presentation, but I will work hard the
>> >> two next monthes to be able to show something impressive :)
>> >>
>> >> For more details (but again, in French) you can check the web site :
>> >> http://devoxx.fr
>> >>
>> >> If some of you plan to come we could try to organize a DM meetup at
>> >> the same time
>> >>
>> >> Cheers,
>> >>
>> >> Benoit.
>> >>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Daniel Manzke <da...@googlemail.com>.
After a short look at the documentation, I wanted to ask, if the
Client-side API should really be so complex? :)
For me it is a little bit hard, that for just retrieving a value from my
cache:
DirectMemoryCacheResponse<Wine> response =
client.retrieve(
new DirectMemoryCacheRequest().setKey( "bordeaux" )
.setSerializer( SerializerFactory.createNewSerializer() )
.setExchangeType( ExchangeType.JSON )
.setObjectClass( Wine.class ) );
I think for the client-side it should be transparent, if you are using a
local or a remote cache.
Means: the complexity should kept from the client. the client should use
the CacheService-Interface
WDYT? :)
(JAX-RS client api? jersey / cxf client api? :))
2012/2/21 Olivier Lamy <ol...@apache.org>
> 2012/2/21 Raffaele P. Guidi <ra...@gmail.com>:
> > And is there already a schedule? I sometimes hang in paris (my employer
> is
> > a french bank) and could have some meeting in that period
>
> AFAIK not yet.
>
> >
> > On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch>
> wrote:
> >
> >> > can you please share more devoxx details please? I could come to
> Paris!
> >>
> >> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
> >> of the presentation will be in French.
> >>
> >> We will present DM under the Tools in Action topic. I still don't know
> >> precisely what will be in the presentation, but I will work hard the
> >> two next monthes to be able to show something impressive :)
> >>
> >> For more details (but again, in French) you can check the web site :
> >> http://devoxx.fr
> >>
> >> If some of you plan to come we could try to organize a DM meetup at
> >> the same time
> >>
> >> Cheers,
> >>
> >> Benoit.
> >>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
--
Viele Grüße/Best Regards
Daniel Manzke
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
2012/2/21 Raffaele P. Guidi <ra...@gmail.com>:
> And is there already a schedule? I sometimes hang in paris (my employer is
> a french bank) and could have some meeting in that period
AFAIK not yet.
>
> On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch> wrote:
>
>> > can you please share more devoxx details please? I could come to Paris!
>>
>> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
>> of the presentation will be in French.
>>
>> We will present DM under the Tools in Action topic. I still don't know
>> precisely what will be in the presentation, but I will work hard the
>> two next monthes to be able to show something impressive :)
>>
>> For more details (but again, in French) you can check the web site :
>> http://devoxx.fr
>>
>> If some of you plan to come we could try to organize a DM meetup at
>> the same time
>>
>> Cheers,
>>
>> Benoit.
>>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
Anyhow: love the docs - Wine bordeaux = new Wine( "Bordeaux", "very great
wine" ); is my favourite code snippet ever ;)
Ciao,
R
On Tue, Feb 21, 2012 at 9:34 AM, Raffaele P. Guidi <
raffaele.p.guidi@gmail.com> wrote:
> And is there already a schedule? I sometimes hang in paris (my employer is
> a french bank) and could have some meeting in that period
>
> On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch>wrote:
>
>> > can you please share more devoxx details please? I could come to Paris!
>>
>> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
>> of the presentation will be in French.
>>
>> We will present DM under the Tools in Action topic. I still don't know
>> precisely what will be in the presentation, but I will work hard the
>> two next monthes to be able to show something impressive :)
>>
>> For more details (but again, in French) you can check the web site :
>> http://devoxx.fr
>>
>> If some of you plan to come we could try to organize a DM meetup at
>> the same time
>>
>> Cheers,
>>
>> Benoit.
>>
>
>
Re: [DISCUSS] RFC Server implementation
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
And is there already a schedule? I sometimes hang in paris (my employer is
a french bank) and could have some meeting in that period
On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch> wrote:
> > can you please share more devoxx details please? I could come to Paris!
>
> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
> of the presentation will be in French.
>
> We will present DM under the Tools in Action topic. I still don't know
> precisely what will be in the presentation, but I will work hard the
> two next monthes to be able to show something impressive :)
>
> For more details (but again, in French) you can check the web site :
> http://devoxx.fr
>
> If some of you plan to come we could try to organize a DM meetup at
> the same time
>
> Cheers,
>
> Benoit.
>
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
Hello,
And documentation started: http://incubator.apache.org/directmemory/server.html
2012/2/20 Simone Tripodi <si...@apache.org>:
> Pas de problems avec la langue Française (si vous ne parlez pas vite,
> que á Paris vous parlez trop rapidement!) ;)
>
> - Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch> wrote:
>>> can you please share more devoxx details please? I could come to Paris!
>>
>> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
>> of the presentation will be in French.
>>
>> We will present DM under the Tools in Action topic. I still don't know
>> precisely what will be in the presentation, but I will work hard the
>> two next monthes to be able to show something impressive :)
>>
>> For more details (but again, in French) you can check the web site :
>> http://devoxx.fr
>>
>> If some of you plan to come we could try to organize a DM meetup at
>> the same time
>>
>> Cheers,
>>
>> Benoit.
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
Pas de problems avec la langue Française (si vous ne parlez pas vite,
que á Paris vous parlez trop rapidement!) ;)
- Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 20, 2012 at 3:55 PM, Benoit Perroud <be...@noisette.ch> wrote:
>> can you please share more devoxx details please? I could come to Paris!
>
> Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
> of the presentation will be in French.
>
> We will present DM under the Tools in Action topic. I still don't know
> precisely what will be in the presentation, but I will work hard the
> two next monthes to be able to show something impressive :)
>
> For more details (but again, in French) you can check the web site :
> http://devoxx.fr
>
> If some of you plan to come we could try to organize a DM meetup at
> the same time
>
> Cheers,
>
> Benoit.
Re: [DISCUSS] RFC Server implementation
Posted by Benoit Perroud <be...@noisette.ch>.
> can you please share more devoxx details please? I could come to Paris!
Devoxx France is a sort of clone of Devoxx, but localized, i.e. most
of the presentation will be in French.
We will present DM under the Tools in Action topic. I still don't know
precisely what will be in the presentation, but I will work hard the
two next monthes to be able to show something impressive :)
For more details (but again, in French) you can check the web site :
http://devoxx.fr
If some of you plan to come we could try to organize a DM meetup at
the same time
Cheers,
Benoit.
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
Salut Benoit,
+1 for the regions - it is something I called "namespaces" in the
early DM days, full support from my side for it.
+0 for the serializer - same cache/region _could_ be accessed bu
different clients using different serialization, anyway +1 for the
region properties.
can you please share more devoxx details please? I could come to Paris!
a trés bientôt!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 20, 2012 at 11:53 AM, Benoit Perroud <be...@noisette.ch> wrote:
> Hi All,
>
> First of all thanks for the warm welcome of the presentation, we'll
> try to spread the word as much as possible.
>
> My idea here would be to have several "cache region", like
>
> ${webPath}/${region}/${key}
>
> and allowing some metadata regarding those regions :
>
> - The serializer (thus no need to pass it at every request)
> - Properties of the region : max size, eviction algorithm, slab size
> (if my new implementation will be selected), ...
>
> Objects of the same nature could be stored in the same "region".
>
> From the actual code base, there is some synchronization done to
> allocate object in a Cache, thus having multiple region/caches in the
> back would allow more concurrency. And would be able to fine tune the
> cache for the objects stored (big almost static files vs small often
> changing objects).
>
> Cheers,
>
> Benoit.
>
>
>
>
> 2012/2/20 Simone Tripodi <si...@apache.org>:
>> Salut!
>>
>>> BTW nothing prevent to have both implementations (based on
>>> Content-Type "application/json;charset=UTF-8" for json model exchange
>>> :-) )
>>
>> sure, that is why I like content type negotiation: same URI, different
>> way to exchange content. Simple & cool at the same time :P
>>
>>> Doh sure we can "win" some packet on network layer :-)
>>>
>>
>> lol, aren't we problem solvers? :D
>>
>>> Ok I will start as it. My first impl (push) will be with json exchange
>>> as I have it locally :-).
>>>
>>> Then I will improve with the "raw" model based on Content-Type and http headers.
>>
>> looking forward to read the code, hope to be helpful!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Feb 20, 2012 at 11:01 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>> Salut!
>>>>
>>>> I see we have 2 different use cases in mind, that is why we are not in sync.
>>>>
>>>> I personally see that adopting your APIs layer, for each request, body
>>>> content has to be serialized in a textual form - no matter how fast it
>>>> is, that means that both client/server need to (de)serialize the
>>>> content.
>>>
>>>>
>>>> The client builds the request -> serialize it in JSON -> creates the
>>>> JSON request -> send it to the server -> the server extract the JSON
>>>> content -> stream it in the memory.
>>> agree it can be a performance "problem".
>>>
>>
>>>
>>>>
>>>> Let's explore more possibilities: you can still map your JSON request
>>>> model to pure HTTP protocol:
>>>>
>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>> json/xml string*
>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>
>>>> would become
>>>>
>>>> +----+
>>>> PUT ${webPath}/${key}
>>>> Content-Type: text/xml
>>> I would prefer use an other Content-Type IMHO
>>> "application/x-java-serialized-object" was a good idea.
>>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>>>
>>>> serialized-body
>>>> +----+
>>>>
>>>> extra non-standard fields can be added via the X- prefix, for example,
>>>> the preference of used serializer to store the content:
>>> Good idea.
>>>>
>>>> +----+
>>>> PUT ${webPath}/${key}
>>>> Content-Type: text/xml
>>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>>> X-DirectMemory-Serializer:
>>>> org.apache.directmemory.serialization.StandardSerializer
>>>>
>>>> serialized-body
>>>> +----+
>>>>
>>>> You should still be able to write the JS httpclient to interact with
>>>> the server - it is just HTTP! - without paying the overhead of more
>>>> parsing operations.
>>>>
>>>> Moreover, if you'll proceed to JSON, I think that the proposed format
>>>> can be thiner:
>>>>
>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>> json/xml string*
>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>
>>>> could be
>>>>
>>>> {"key":"101","expiresIn":123,"cacheContent":"*here a
>>>> json/xml string*
>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}
>>>>
>>>> dropping the DirectMemoryRQ container (it is yet another data structure :P)
>>>
>>> Doh sure we can "win" some packet on network layer :-)
>>>
>>> Ok I will start as it. My first impl (push) will be with json exchange
>>> as I have it locally :-).
>>>
>>> Then I will improve with the "raw" model based on Content-Type and http headers.
>>>
>>>>
>>>> Thanks for brainstorming!
>>>
>>> You're welcome :P
>>>
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>>> Hello,
>>>>>
>>>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>>>>> Hmmmm. Simone should answer this.
>>>>>>>
>>>>>>> If I'm really thinking about it, the content-type makes no sense. ;)
>>>>>>
>>>>>> it does instead, because the server has to be able to reply the
>>>>>> serialization content type when clients ask for stored - or you expect
>>>>>> the client automagically understands it? Or you expect to have just
>>>>>> one client type per application, so the serialization type is always
>>>>>> the same? Couldn't servers be populated by heterogeneous clients that
>>>>>> read each other data?
>>>>> The client will be responsible for de/serialization.
>>>>> My preference for more "complex" content is for new feature and
>>>>> enhance cache request/response with new field.
>>>>>
>>>>> retrieve object :
>>>>> GET on ${webPath}/cache/${key}
>>>>>
>>>>> return json content if found
>>>>>
>>>>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>>>> Using this format we will be able to add new fields in the ison
>>>>> "object" (cacheAge etc...)
>>>>>
>>>>> PUT on ${webPath}/cache
>>>>>
>>>>> json content posted
>>>>>
>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>
>>>>> Again using a json "object" we will be able to easily add new "fields".
>>>>>
>>>>> Why using json I have in mind using cache access directly tru a
>>>>> javascript application with something like :
>>>>>
>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>>> json/xml string*
>>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>
>>>>> As it the server we will be able to serialize then store the json/xml content.
>>>>> And you can use directly from your javascript application.
>>>>>
>>>>> Compare to an Api.
>>>>>
>>>>> wineService.findWine(year, name)
>>>>>
>>>>> wineService.find(wineSearchRequest)
>>>>>
>>>>> With
>>>>> WineSearchRequest {
>>>>> year;
>>>>> name;
>>>>> }
>>>>>
>>>>> I tend to prefer using the second pattern as it's more easy to improve
>>>>> the model without breaking (normally :-) ) the backward comp.
>>>>>
>>>>> Makes sense ?
>>>>>
>>>>>>
>>>>>> "makes no sense" is a hard assertion, I always think more than twice
>>>>>> before saying that ;)
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> sent from my Nokia 3210
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
Salut!
a part that the request you described in some cases replies 400 Bad
Request ;) , text/plain is fine :)
if you already have in mind an XML format for describing the server
config, I would be glad to plug quickly the digester :)
A trés bientôt!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 20, 2012 at 3:04 PM, Olivier Lamy <ol...@apache.org> wrote:
> Yup for region but what about having a fix uri ?
> And adding that in a http header or new field in the json request ?
>
> @Simone
> Regarding raw plain text mode, I would prefer something content type
> text/plain like (a real sample below :P )
>
> PUT PUT ${webPath}/the truth
> Content-Type: text/plain
> Expires: Thu, 01 Dec 2099 16:00:00 GMT
> X-DirectMemory-Serializer:
> org.apache.directmemory.serialization.StandardSerializer
> French Wine is better than Italian Wine.
>
>
> Something else I have in mind is the server configuration.
> My current impl (as it can be improved easily later) is System
> Property based and only one cache/region.
>
> // TODO some configuration for cacheService.init( .... );
> different from sysproperties
> //int numberOfBuffers, int size, int initialCapacity, int
> concurrencyLevel
> int numberOfBuffers = Integer.getInteger(
> "directMemory.numberOfBuffers", 1000 );
> int size = Integer.getInteger( "directMemory.size", 10 );
> int initialCapacity =
> Integer.getInteger( "directMemory.initialCapacity",
> CacheService.DEFAULT_INITIAL_CAPACITY );
> int concurrencyLevel =
> Integer.getInteger( "directMemory.concurrencyLevel",
> CacheService.DEFAULT_CONCURRENCY_LEVEL );
> cacheService.init( numberOfBuffers, size, initialCapacity,
> concurrencyLevel );
>
> What about a xml configuration file (maybe using digester :-) )?
>
>
> 2012/2/20 Benoit Perroud <be...@noisette.ch>:
>> Hi All,
>>
>> First of all thanks for the warm welcome of the presentation, we'll
>> try to spread the word as much as possible.
>>
>> My idea here would be to have several "cache region", like
>>
>> ${webPath}/${region}/${key}
>>
>> and allowing some metadata regarding those regions :
>>
>> - The serializer (thus no need to pass it at every request)
>> - Properties of the region : max size, eviction algorithm, slab size
>> (if my new implementation will be selected), ...
>>
>> Objects of the same nature could be stored in the same "region".
>>
>> From the actual code base, there is some synchronization done to
>> allocate object in a Cache, thus having multiple region/caches in the
>> back would allow more concurrency. And would be able to fine tune the
>> cache for the objects stored (big almost static files vs small often
>> changing objects).
>>
>> Cheers,
>>
>> Benoit.
>>
>>
>>
>>
>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>> Salut!
>>>
>>>> BTW nothing prevent to have both implementations (based on
>>>> Content-Type "application/json;charset=UTF-8" for json model exchange
>>>> :-) )
>>>
>>> sure, that is why I like content type negotiation: same URI, different
>>> way to exchange content. Simple & cool at the same time :P
>>>
>>>> Doh sure we can "win" some packet on network layer :-)
>>>>
>>>
>>> lol, aren't we problem solvers? :D
>>>
>>>> Ok I will start as it. My first impl (push) will be with json exchange
>>>> as I have it locally :-).
>>>>
>>>> Then I will improve with the "raw" model based on Content-Type and http headers.
>>>
>>> looking forward to read the code, hope to be helpful!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Feb 20, 2012 at 11:01 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>>> Salut!
>>>>>
>>>>> I see we have 2 different use cases in mind, that is why we are not in sync.
>>>>>
>>>>> I personally see that adopting your APIs layer, for each request, body
>>>>> content has to be serialized in a textual form - no matter how fast it
>>>>> is, that means that both client/server need to (de)serialize the
>>>>> content.
>>>>
>>>>>
>>>>> The client builds the request -> serialize it in JSON -> creates the
>>>>> JSON request -> send it to the server -> the server extract the JSON
>>>>> content -> stream it in the memory.
>>>> agree it can be a performance "problem".
>>>>
>>>
>>>>
>>>>>
>>>>> Let's explore more possibilities: you can still map your JSON request
>>>>> model to pure HTTP protocol:
>>>>>
>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>>> json/xml string*
>>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>
>>>>> would become
>>>>>
>>>>> +----+
>>>>> PUT ${webPath}/${key}
>>>>> Content-Type: text/xml
>>>> I would prefer use an other Content-Type IMHO
>>>> "application/x-java-serialized-object" was a good idea.
>>>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>>>>
>>>>> serialized-body
>>>>> +----+
>>>>>
>>>>> extra non-standard fields can be added via the X- prefix, for example,
>>>>> the preference of used serializer to store the content:
>>>> Good idea.
>>>>>
>>>>> +----+
>>>>> PUT ${webPath}/${key}
>>>>> Content-Type: text/xml
>>>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>>>> X-DirectMemory-Serializer:
>>>>> org.apache.directmemory.serialization.StandardSerializer
>>>>>
>>>>> serialized-body
>>>>> +----+
>>>>>
>>>>> You should still be able to write the JS httpclient to interact with
>>>>> the server - it is just HTTP! - without paying the overhead of more
>>>>> parsing operations.
>>>>>
>>>>> Moreover, if you'll proceed to JSON, I think that the proposed format
>>>>> can be thiner:
>>>>>
>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>>> json/xml string*
>>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>
>>>>> could be
>>>>>
>>>>> {"key":"101","expiresIn":123,"cacheContent":"*here a
>>>>> json/xml string*
>>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}
>>>>>
>>>>> dropping the DirectMemoryRQ container (it is yet another data structure :P)
>>>>
>>>> Doh sure we can "win" some packet on network layer :-)
>>>>
>>>> Ok I will start as it. My first impl (push) will be with json exchange
>>>> as I have it locally :-).
>>>>
>>>> Then I will improve with the "raw" model based on Content-Type and http headers.
>>>>
>>>>>
>>>>> Thanks for brainstorming!
>>>>
>>>> You're welcome :P
>>>>
>>>>> -Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>>>>>> Hmmmm. Simone should answer this.
>>>>>>>>
>>>>>>>> If I'm really thinking about it, the content-type makes no sense. ;)
>>>>>>>
>>>>>>> it does instead, because the server has to be able to reply the
>>>>>>> serialization content type when clients ask for stored - or you expect
>>>>>>> the client automagically understands it? Or you expect to have just
>>>>>>> one client type per application, so the serialization type is always
>>>>>>> the same? Couldn't servers be populated by heterogeneous clients that
>>>>>>> read each other data?
>>>>>> The client will be responsible for de/serialization.
>>>>>> My preference for more "complex" content is for new feature and
>>>>>> enhance cache request/response with new field.
>>>>>>
>>>>>> retrieve object :
>>>>>> GET on ${webPath}/cache/${key}
>>>>>>
>>>>>> return json content if found
>>>>>>
>>>>>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>>>>> Using this format we will be able to add new fields in the ison
>>>>>> "object" (cacheAge etc...)
>>>>>>
>>>>>> PUT on ${webPath}/cache
>>>>>>
>>>>>> json content posted
>>>>>>
>>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>>
>>>>>> Again using a json "object" we will be able to easily add new "fields".
>>>>>>
>>>>>> Why using json I have in mind using cache access directly tru a
>>>>>> javascript application with something like :
>>>>>>
>>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>>>> json/xml string*
>>>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>>
>>>>>> As it the server we will be able to serialize then store the json/xml content.
>>>>>> And you can use directly from your javascript application.
>>>>>>
>>>>>> Compare to an Api.
>>>>>>
>>>>>> wineService.findWine(year, name)
>>>>>>
>>>>>> wineService.find(wineSearchRequest)
>>>>>>
>>>>>> With
>>>>>> WineSearchRequest {
>>>>>> year;
>>>>>> name;
>>>>>> }
>>>>>>
>>>>>> I tend to prefer using the second pattern as it's more easy to improve
>>>>>> the model without breaking (normally :-) ) the backward comp.
>>>>>>
>>>>>> Makes sense ?
>>>>>>
>>>>>>>
>>>>>>> "makes no sense" is a hard assertion, I always think more than twice
>>>>>>> before saying that ;)
>>>>>>>
>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>> http://twitter.com/simonetripodi
>>>>>>> http://www.99soft.org/
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>>
>> --
>> sent from my Nokia 3210
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
Yup for region but what about having a fix uri ?
And adding that in a http header or new field in the json request ?
@Simone
Regarding raw plain text mode, I would prefer something content type
text/plain like (a real sample below :P )
PUT PUT ${webPath}/the truth
Content-Type: text/plain
Expires: Thu, 01 Dec 2099 16:00:00 GMT
X-DirectMemory-Serializer:
org.apache.directmemory.serialization.StandardSerializer
French Wine is better than Italian Wine.
Something else I have in mind is the server configuration.
My current impl (as it can be improved easily later) is System
Property based and only one cache/region.
// TODO some configuration for cacheService.init( .... );
different from sysproperties
//int numberOfBuffers, int size, int initialCapacity, int
concurrencyLevel
int numberOfBuffers = Integer.getInteger(
"directMemory.numberOfBuffers", 1000 );
int size = Integer.getInteger( "directMemory.size", 10 );
int initialCapacity =
Integer.getInteger( "directMemory.initialCapacity",
CacheService.DEFAULT_INITIAL_CAPACITY );
int concurrencyLevel =
Integer.getInteger( "directMemory.concurrencyLevel",
CacheService.DEFAULT_CONCURRENCY_LEVEL );
cacheService.init( numberOfBuffers, size, initialCapacity,
concurrencyLevel );
What about a xml configuration file (maybe using digester :-) )?
2012/2/20 Benoit Perroud <be...@noisette.ch>:
> Hi All,
>
> First of all thanks for the warm welcome of the presentation, we'll
> try to spread the word as much as possible.
>
> My idea here would be to have several "cache region", like
>
> ${webPath}/${region}/${key}
>
> and allowing some metadata regarding those regions :
>
> - The serializer (thus no need to pass it at every request)
> - Properties of the region : max size, eviction algorithm, slab size
> (if my new implementation will be selected), ...
>
> Objects of the same nature could be stored in the same "region".
>
> From the actual code base, there is some synchronization done to
> allocate object in a Cache, thus having multiple region/caches in the
> back would allow more concurrency. And would be able to fine tune the
> cache for the objects stored (big almost static files vs small often
> changing objects).
>
> Cheers,
>
> Benoit.
>
>
>
>
> 2012/2/20 Simone Tripodi <si...@apache.org>:
>> Salut!
>>
>>> BTW nothing prevent to have both implementations (based on
>>> Content-Type "application/json;charset=UTF-8" for json model exchange
>>> :-) )
>>
>> sure, that is why I like content type negotiation: same URI, different
>> way to exchange content. Simple & cool at the same time :P
>>
>>> Doh sure we can "win" some packet on network layer :-)
>>>
>>
>> lol, aren't we problem solvers? :D
>>
>>> Ok I will start as it. My first impl (push) will be with json exchange
>>> as I have it locally :-).
>>>
>>> Then I will improve with the "raw" model based on Content-Type and http headers.
>>
>> looking forward to read the code, hope to be helpful!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Feb 20, 2012 at 11:01 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>> Salut!
>>>>
>>>> I see we have 2 different use cases in mind, that is why we are not in sync.
>>>>
>>>> I personally see that adopting your APIs layer, for each request, body
>>>> content has to be serialized in a textual form - no matter how fast it
>>>> is, that means that both client/server need to (de)serialize the
>>>> content.
>>>
>>>>
>>>> The client builds the request -> serialize it in JSON -> creates the
>>>> JSON request -> send it to the server -> the server extract the JSON
>>>> content -> stream it in the memory.
>>> agree it can be a performance "problem".
>>>
>>
>>>
>>>>
>>>> Let's explore more possibilities: you can still map your JSON request
>>>> model to pure HTTP protocol:
>>>>
>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>> json/xml string*
>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>
>>>> would become
>>>>
>>>> +----+
>>>> PUT ${webPath}/${key}
>>>> Content-Type: text/xml
>>> I would prefer use an other Content-Type IMHO
>>> "application/x-java-serialized-object" was a good idea.
>>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>>>
>>>> serialized-body
>>>> +----+
>>>>
>>>> extra non-standard fields can be added via the X- prefix, for example,
>>>> the preference of used serializer to store the content:
>>> Good idea.
>>>>
>>>> +----+
>>>> PUT ${webPath}/${key}
>>>> Content-Type: text/xml
>>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>>> X-DirectMemory-Serializer:
>>>> org.apache.directmemory.serialization.StandardSerializer
>>>>
>>>> serialized-body
>>>> +----+
>>>>
>>>> You should still be able to write the JS httpclient to interact with
>>>> the server - it is just HTTP! - without paying the overhead of more
>>>> parsing operations.
>>>>
>>>> Moreover, if you'll proceed to JSON, I think that the proposed format
>>>> can be thiner:
>>>>
>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>> json/xml string*
>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>
>>>> could be
>>>>
>>>> {"key":"101","expiresIn":123,"cacheContent":"*here a
>>>> json/xml string*
>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}
>>>>
>>>> dropping the DirectMemoryRQ container (it is yet another data structure :P)
>>>
>>> Doh sure we can "win" some packet on network layer :-)
>>>
>>> Ok I will start as it. My first impl (push) will be with json exchange
>>> as I have it locally :-).
>>>
>>> Then I will improve with the "raw" model based on Content-Type and http headers.
>>>
>>>>
>>>> Thanks for brainstorming!
>>>
>>> You're welcome :P
>>>
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>>> Hello,
>>>>>
>>>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>>>>> Hmmmm. Simone should answer this.
>>>>>>>
>>>>>>> If I'm really thinking about it, the content-type makes no sense. ;)
>>>>>>
>>>>>> it does instead, because the server has to be able to reply the
>>>>>> serialization content type when clients ask for stored - or you expect
>>>>>> the client automagically understands it? Or you expect to have just
>>>>>> one client type per application, so the serialization type is always
>>>>>> the same? Couldn't servers be populated by heterogeneous clients that
>>>>>> read each other data?
>>>>> The client will be responsible for de/serialization.
>>>>> My preference for more "complex" content is for new feature and
>>>>> enhance cache request/response with new field.
>>>>>
>>>>> retrieve object :
>>>>> GET on ${webPath}/cache/${key}
>>>>>
>>>>> return json content if found
>>>>>
>>>>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>>>> Using this format we will be able to add new fields in the ison
>>>>> "object" (cacheAge etc...)
>>>>>
>>>>> PUT on ${webPath}/cache
>>>>>
>>>>> json content posted
>>>>>
>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>
>>>>> Again using a json "object" we will be able to easily add new "fields".
>>>>>
>>>>> Why using json I have in mind using cache access directly tru a
>>>>> javascript application with something like :
>>>>>
>>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>>> json/xml string*
>>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>>
>>>>> As it the server we will be able to serialize then store the json/xml content.
>>>>> And you can use directly from your javascript application.
>>>>>
>>>>> Compare to an Api.
>>>>>
>>>>> wineService.findWine(year, name)
>>>>>
>>>>> wineService.find(wineSearchRequest)
>>>>>
>>>>> With
>>>>> WineSearchRequest {
>>>>> year;
>>>>> name;
>>>>> }
>>>>>
>>>>> I tend to prefer using the second pattern as it's more easy to improve
>>>>> the model without breaking (normally :-) ) the backward comp.
>>>>>
>>>>> Makes sense ?
>>>>>
>>>>>>
>>>>>> "makes no sense" is a hard assertion, I always think more than twice
>>>>>> before saying that ;)
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> sent from my Nokia 3210
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Benoit Perroud <be...@noisette.ch>.
Hi All,
First of all thanks for the warm welcome of the presentation, we'll
try to spread the word as much as possible.
My idea here would be to have several "cache region", like
${webPath}/${region}/${key}
and allowing some metadata regarding those regions :
- The serializer (thus no need to pass it at every request)
- Properties of the region : max size, eviction algorithm, slab size
(if my new implementation will be selected), ...
Objects of the same nature could be stored in the same "region".
>From the actual code base, there is some synchronization done to
allocate object in a Cache, thus having multiple region/caches in the
back would allow more concurrency. And would be able to fine tune the
cache for the objects stored (big almost static files vs small often
changing objects).
Cheers,
Benoit.
2012/2/20 Simone Tripodi <si...@apache.org>:
> Salut!
>
>> BTW nothing prevent to have both implementations (based on
>> Content-Type "application/json;charset=UTF-8" for json model exchange
>> :-) )
>
> sure, that is why I like content type negotiation: same URI, different
> way to exchange content. Simple & cool at the same time :P
>
>> Doh sure we can "win" some packet on network layer :-)
>>
>
> lol, aren't we problem solvers? :D
>
>> Ok I will start as it. My first impl (push) will be with json exchange
>> as I have it locally :-).
>>
>> Then I will improve with the "raw" model based on Content-Type and http headers.
>
> looking forward to read the code, hope to be helpful!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Feb 20, 2012 at 11:01 AM, Olivier Lamy <ol...@apache.org> wrote:
>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>> Salut!
>>>
>>> I see we have 2 different use cases in mind, that is why we are not in sync.
>>>
>>> I personally see that adopting your APIs layer, for each request, body
>>> content has to be serialized in a textual form - no matter how fast it
>>> is, that means that both client/server need to (de)serialize the
>>> content.
>>
>>>
>>> The client builds the request -> serialize it in JSON -> creates the
>>> JSON request -> send it to the server -> the server extract the JSON
>>> content -> stream it in the memory.
>> agree it can be a performance "problem".
>>
>
>>
>>>
>>> Let's explore more possibilities: you can still map your JSON request
>>> model to pure HTTP protocol:
>>>
>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>> json/xml string*
>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>
>>> would become
>>>
>>> +----+
>>> PUT ${webPath}/${key}
>>> Content-Type: text/xml
>> I would prefer use an other Content-Type IMHO
>> "application/x-java-serialized-object" was a good idea.
>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>>
>>> serialized-body
>>> +----+
>>>
>>> extra non-standard fields can be added via the X- prefix, for example,
>>> the preference of used serializer to store the content:
>> Good idea.
>>>
>>> +----+
>>> PUT ${webPath}/${key}
>>> Content-Type: text/xml
>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>> X-DirectMemory-Serializer:
>>> org.apache.directmemory.serialization.StandardSerializer
>>>
>>> serialized-body
>>> +----+
>>>
>>> You should still be able to write the JS httpclient to interact with
>>> the server - it is just HTTP! - without paying the overhead of more
>>> parsing operations.
>>>
>>> Moreover, if you'll proceed to JSON, I think that the proposed format
>>> can be thiner:
>>>
>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>> json/xml string*
>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>
>>> could be
>>>
>>> {"key":"101","expiresIn":123,"cacheContent":"*here a
>>> json/xml string*
>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}
>>>
>>> dropping the DirectMemoryRQ container (it is yet another data structure :P)
>>
>> Doh sure we can "win" some packet on network layer :-)
>>
>> Ok I will start as it. My first impl (push) will be with json exchange
>> as I have it locally :-).
>>
>> Then I will improve with the "raw" model based on Content-Type and http headers.
>>
>>>
>>> Thanks for brainstorming!
>>
>> You're welcome :P
>>
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>> Hello,
>>>>
>>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>>>> Hmmmm. Simone should answer this.
>>>>>>
>>>>>> If I'm really thinking about it, the content-type makes no sense. ;)
>>>>>
>>>>> it does instead, because the server has to be able to reply the
>>>>> serialization content type when clients ask for stored - or you expect
>>>>> the client automagically understands it? Or you expect to have just
>>>>> one client type per application, so the serialization type is always
>>>>> the same? Couldn't servers be populated by heterogeneous clients that
>>>>> read each other data?
>>>> The client will be responsible for de/serialization.
>>>> My preference for more "complex" content is for new feature and
>>>> enhance cache request/response with new field.
>>>>
>>>> retrieve object :
>>>> GET on ${webPath}/cache/${key}
>>>>
>>>> return json content if found
>>>>
>>>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>>> Using this format we will be able to add new fields in the ison
>>>> "object" (cacheAge etc...)
>>>>
>>>> PUT on ${webPath}/cache
>>>>
>>>> json content posted
>>>>
>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>
>>>> Again using a json "object" we will be able to easily add new "fields".
>>>>
>>>> Why using json I have in mind using cache access directly tru a
>>>> javascript application with something like :
>>>>
>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>>> json/xml string*
>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>>
>>>> As it the server we will be able to serialize then store the json/xml content.
>>>> And you can use directly from your javascript application.
>>>>
>>>> Compare to an Api.
>>>>
>>>> wineService.findWine(year, name)
>>>>
>>>> wineService.find(wineSearchRequest)
>>>>
>>>> With
>>>> WineSearchRequest {
>>>> year;
>>>> name;
>>>> }
>>>>
>>>> I tend to prefer using the second pattern as it's more easy to improve
>>>> the model without breaking (normally :-) ) the backward comp.
>>>>
>>>> Makes sense ?
>>>>
>>>>>
>>>>> "makes no sense" is a hard assertion, I always think more than twice
>>>>> before saying that ;)
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
sent from my Nokia 3210
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
Salut!
> BTW nothing prevent to have both implementations (based on
> Content-Type "application/json;charset=UTF-8" for json model exchange
> :-) )
sure, that is why I like content type negotiation: same URI, different
way to exchange content. Simple & cool at the same time :P
> Doh sure we can "win" some packet on network layer :-)
>
lol, aren't we problem solvers? :D
> Ok I will start as it. My first impl (push) will be with json exchange
> as I have it locally :-).
>
> Then I will improve with the "raw" model based on Content-Type and http headers.
looking forward to read the code, hope to be helpful!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 20, 2012 at 11:01 AM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/2/20 Simone Tripodi <si...@apache.org>:
>> Salut!
>>
>> I see we have 2 different use cases in mind, that is why we are not in sync.
>>
>> I personally see that adopting your APIs layer, for each request, body
>> content has to be serialized in a textual form - no matter how fast it
>> is, that means that both client/server need to (de)serialize the
>> content.
>
>>
>> The client builds the request -> serialize it in JSON -> creates the
>> JSON request -> send it to the server -> the server extract the JSON
>> content -> stream it in the memory.
> agree it can be a performance "problem".
>
>
>>
>> Let's explore more possibilities: you can still map your JSON request
>> model to pure HTTP protocol:
>>
>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>> json/xml string*
>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>
>> would become
>>
>> +----+
>> PUT ${webPath}/${key}
>> Content-Type: text/xml
> I would prefer use an other Content-Type IMHO
> "application/x-java-serialized-object" was a good idea.
>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>>
>> serialized-body
>> +----+
>>
>> extra non-standard fields can be added via the X- prefix, for example,
>> the preference of used serializer to store the content:
> Good idea.
>>
>> +----+
>> PUT ${webPath}/${key}
>> Content-Type: text/xml
>> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>> X-DirectMemory-Serializer:
>> org.apache.directmemory.serialization.StandardSerializer
>>
>> serialized-body
>> +----+
>>
>> You should still be able to write the JS httpclient to interact with
>> the server - it is just HTTP! - without paying the overhead of more
>> parsing operations.
>>
>> Moreover, if you'll proceed to JSON, I think that the proposed format
>> can be thiner:
>>
>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>> json/xml string*
>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>
>> could be
>>
>> {"key":"101","expiresIn":123,"cacheContent":"*here a
>> json/xml string*
>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}
>>
>> dropping the DirectMemoryRQ container (it is yet another data structure :P)
>
> Doh sure we can "win" some packet on network layer :-)
>
> Ok I will start as it. My first impl (push) will be with json exchange
> as I have it locally :-).
>
> Then I will improve with the "raw" model based on Content-Type and http headers.
>
>>
>> Thanks for brainstorming!
>
> You're welcome :P
>
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> Hello,
>>>
>>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>>> Hmmmm. Simone should answer this.
>>>>>
>>>>> If I'm really thinking about it, the content-type makes no sense. ;)
>>>>
>>>> it does instead, because the server has to be able to reply the
>>>> serialization content type when clients ask for stored - or you expect
>>>> the client automagically understands it? Or you expect to have just
>>>> one client type per application, so the serialization type is always
>>>> the same? Couldn't servers be populated by heterogeneous clients that
>>>> read each other data?
>>> The client will be responsible for de/serialization.
>>> My preference for more "complex" content is for new feature and
>>> enhance cache request/response with new field.
>>>
>>> retrieve object :
>>> GET on ${webPath}/cache/${key}
>>>
>>> return json content if found
>>>
>>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>> Using this format we will be able to add new fields in the ison
>>> "object" (cacheAge etc...)
>>>
>>> PUT on ${webPath}/cache
>>>
>>> json content posted
>>>
>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>
>>> Again using a json "object" we will be able to easily add new "fields".
>>>
>>> Why using json I have in mind using cache access directly tru a
>>> javascript application with something like :
>>>
>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>>> json/xml string*
>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>>
>>> As it the server we will be able to serialize then store the json/xml content.
>>> And you can use directly from your javascript application.
>>>
>>> Compare to an Api.
>>>
>>> wineService.findWine(year, name)
>>>
>>> wineService.find(wineSearchRequest)
>>>
>>> With
>>> WineSearchRequest {
>>> year;
>>> name;
>>> }
>>>
>>> I tend to prefer using the second pattern as it's more easy to improve
>>> the model without breaking (normally :-) ) the backward comp.
>>>
>>> Makes sense ?
>>>
>>>>
>>>> "makes no sense" is a hard assertion, I always think more than twice
>>>> before saying that ;)
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
2012/2/20 Simone Tripodi <si...@apache.org>:
> Salut!
>
> I see we have 2 different use cases in mind, that is why we are not in sync.
>
> I personally see that adopting your APIs layer, for each request, body
> content has to be serialized in a textual form - no matter how fast it
> is, that means that both client/server need to (de)serialize the
> content.
>
> The client builds the request -> serialize it in JSON -> creates the
> JSON request -> send it to the server -> the server extract the JSON
> content -> stream it in the memory.
agree it can be a performance "problem".
BTW nothing prevent to have both implementations (based on
Content-Type "application/json;charset=UTF-8" for json model exchange
:-) )
>
> Let's explore more possibilities: you can still map your JSON request
> model to pure HTTP protocol:
>
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
> json/xml string*
> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>
> would become
>
> +----+
> PUT ${webPath}/${key}
> Content-Type: text/xml
I would prefer use an other Content-Type IMHO
"application/x-java-serialized-object" was a good idea.
> Expires: Thu, 01 Dec 2012 16:00:00 GMT
>
> serialized-body
> +----+
>
> extra non-standard fields can be added via the X- prefix, for example,
> the preference of used serializer to store the content:
Good idea.
>
> +----+
> PUT ${webPath}/${key}
> Content-Type: text/xml
> Expires: Thu, 01 Dec 2012 16:00:00 GMT
> X-DirectMemory-Serializer:
> org.apache.directmemory.serialization.StandardSerializer
>
> serialized-body
> +----+
>
> You should still be able to write the JS httpclient to interact with
> the server - it is just HTTP! - without paying the overhead of more
> parsing operations.
>
> Moreover, if you'll proceed to JSON, I think that the proposed format
> can be thiner:
>
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
> json/xml string*
> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>
> could be
>
> {"key":"101","expiresIn":123,"cacheContent":"*here a
> json/xml string*
> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}
>
> dropping the DirectMemoryRQ container (it is yet another data structure :P)
Doh sure we can "win" some packet on network layer :-)
Ok I will start as it. My first impl (push) will be with json exchange
as I have it locally :-).
Then I will improve with the "raw" model based on Content-Type and http headers.
>
> Thanks for brainstorming!
You're welcome :P
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <ol...@apache.org> wrote:
>> Hello,
>>
>> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>>> Hmmmm. Simone should answer this.
>>>>
>>>> If I'm really thinking about it, the content-type makes no sense. ;)
>>>
>>> it does instead, because the server has to be able to reply the
>>> serialization content type when clients ask for stored - or you expect
>>> the client automagically understands it? Or you expect to have just
>>> one client type per application, so the serialization type is always
>>> the same? Couldn't servers be populated by heterogeneous clients that
>>> read each other data?
>> The client will be responsible for de/serialization.
>> My preference for more "complex" content is for new feature and
>> enhance cache request/response with new field.
>>
>> retrieve object :
>> GET on ${webPath}/cache/${key}
>>
>> return json content if found
>>
>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>> Using this format we will be able to add new fields in the ison
>> "object" (cacheAge etc...)
>>
>> PUT on ${webPath}/cache
>>
>> json content posted
>>
>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>
>> Again using a json "object" we will be able to easily add new "fields".
>>
>> Why using json I have in mind using cache access directly tru a
>> javascript application with something like :
>>
>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
>> json/xml string*
>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>
>> As it the server we will be able to serialize then store the json/xml content.
>> And you can use directly from your javascript application.
>>
>> Compare to an Api.
>>
>> wineService.findWine(year, name)
>>
>> wineService.find(wineSearchRequest)
>>
>> With
>> WineSearchRequest {
>> year;
>> name;
>> }
>>
>> I tend to prefer using the second pattern as it's more easy to improve
>> the model without breaking (normally :-) ) the backward comp.
>>
>> Makes sense ?
>>
>>>
>>> "makes no sense" is a hard assertion, I always think more than twice
>>> before saying that ;)
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
Salut!
I see we have 2 different use cases in mind, that is why we are not in sync.
I personally see that adopting your APIs layer, for each request, body
content has to be serialized in a textual form - no matter how fast it
is, that means that both client/server need to (de)serialize the
content.
The client builds the request -> serialize it in JSON -> creates the
JSON request -> send it to the server -> the server extract the JSON
content -> stream it in the memory.
Let's explore more possibilities: you can still map your JSON request
model to pure HTTP protocol:
{"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
json/xml string*
","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
would become
+----+
PUT ${webPath}/${key}
Content-Type: text/xml
Expires: Thu, 01 Dec 2012 16:00:00 GMT
serialized-body
+----+
extra non-standard fields can be added via the X- prefix, for example,
the preference of used serializer to store the content:
+----+
PUT ${webPath}/${key}
Content-Type: text/xml
Expires: Thu, 01 Dec 2012 16:00:00 GMT
X-DirectMemory-Serializer:
org.apache.directmemory.serialization.StandardSerializer
serialized-body
+----+
You should still be able to write the JS httpclient to interact with
the server - it is just HTTP! - without paying the overhead of more
parsing operations.
Moreover, if you'll proceed to JSON, I think that the proposed format
can be thiner:
{"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
json/xml string*
","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
could be
{"key":"101","expiresIn":123,"cacheContent":"*here a
json/xml string*
","serializer":"org.apache.directmemory.serialization.StandardSerializer"}
dropping the DirectMemoryRQ container (it is yet another data structure :P)
Thanks for brainstorming!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <ol...@apache.org> wrote:
> Hello,
>
> 2012/2/20 Simone Tripodi <si...@apache.org>:
>>> Hmmmm. Simone should answer this.
>>>
>>> If I'm really thinking about it, the content-type makes no sense. ;)
>>
>> it does instead, because the server has to be able to reply the
>> serialization content type when clients ask for stored - or you expect
>> the client automagically understands it? Or you expect to have just
>> one client type per application, so the serialization type is always
>> the same? Couldn't servers be populated by heterogeneous clients that
>> read each other data?
> The client will be responsible for de/serialization.
> My preference for more "complex" content is for new feature and
> enhance cache request/response with new field.
>
> retrieve object :
> GET on ${webPath}/cache/${key}
>
> return json content if found
>
> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
> Using this format we will be able to add new fields in the ison
> "object" (cacheAge etc...)
>
> PUT on ${webPath}/cache
>
> json content posted
>
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>
> Again using a json "object" we will be able to easily add new "fields".
>
> Why using json I have in mind using cache access directly tru a
> javascript application with something like :
>
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
> json/xml string*
> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>
> As it the server we will be able to serialize then store the json/xml content.
> And you can use directly from your javascript application.
>
> Compare to an Api.
>
> wineService.findWine(year, name)
>
> wineService.find(wineSearchRequest)
>
> With
> WineSearchRequest {
> year;
> name;
> }
>
> I tend to prefer using the second pattern as it's more easy to improve
> the model without breaking (normally :-) ) the backward comp.
>
> Makes sense ?
>
>>
>> "makes no sense" is a hard assertion, I always think more than twice
>> before saying that ;)
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
Hello,
2012/2/20 Simone Tripodi <si...@apache.org>:
>> Hmmmm. Simone should answer this.
>>
>> If I'm really thinking about it, the content-type makes no sense. ;)
>
> it does instead, because the server has to be able to reply the
> serialization content type when clients ask for stored - or you expect
> the client automagically understands it? Or you expect to have just
> one client type per application, so the serialization type is always
> the same? Couldn't servers be populated by heterogeneous clients that
> read each other data?
The client will be responsible for de/serialization.
My preference for more "complex" content is for new feature and
enhance cache request/response with new field.
retrieve object :
GET on ${webPath}/cache/${key}
return json content if found
{"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
Using this format we will be able to add new fields in the ison
"object" (cacheAge etc...)
PUT on ${webPath}/cache
json content posted
{"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
Again using a json "object" we will be able to easily add new "fields".
Why using json I have in mind using cache access directly tru a
javascript application with something like :
{"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a
json/xml string*
","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
As it the server we will be able to serialize then store the json/xml content.
And you can use directly from your javascript application.
Compare to an Api.
wineService.findWine(year, name)
wineService.find(wineSearchRequest)
With
WineSearchRequest {
year;
name;
}
I tend to prefer using the second pattern as it's more easy to improve
the model without breaking (normally :-) ) the backward comp.
Makes sense ?
>
> "makes no sense" is a hard assertion, I always think more than twice
> before saying that ;)
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
> Hmmmm. Simone should answer this.
>
> If I'm really thinking about it, the content-type makes no sense. ;)
it does instead, because the server has to be able to reply the
serialization content type when clients ask for stored - or you expect
the client automagically understands it? Or you expect to have just
one client type per application, so the serialization type is always
the same? Couldn't servers be populated by heterogeneous clients that
read each other data?
"makes no sense" is a hard assertion, I always think more than twice
before saying that ;)
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [DISCUSS] RFC Server implementation
Posted by Daniel Manzke <da...@googlemail.com>.
Hmmmm. Simone should answer this.
If I'm really thinking about it, the content-type makes no sense. ;) (you
are right olivier) Because the client has already serialized it, when it
will be send to server.
The server is only storing a binary object. For the server it is not
interesting, what kind of object the value is.
Bye,
Daniel
2012/2/20 Olivier Lamy <ol...@apache.org>
> Agree on suggestion and the raw servlet model.
> BTW I don't follow/understand you regarding the Content-Type.
> It's just to say the serializer used ? Because Object to cache must be
> serialized on client side before going to the server.
>
> 2012/2/19 Daniel Manzke <da...@googlemail.com>:
> > (after another long discussion with simone ;))
> >
> > +1 for the content-type idea. I think there should be a server-side
> > configuration, where you can map content-type to serializers.
> >
> > Like mentioned before, I would add a cache "layer" in the path, so you
> can
> > add new caches at runtime. (necessary for cloud env? :))
> Why not even if the goal was not really to have more than direct
> memory impl on server side :-)
> >
> > BTW: What comes after the cloud? The sky! :P
> >
> > New/update entry: PUT on ${webPath}/${key} -> body has the object which
> > should be serialized
> > Contains entry: HEAD on ${webPath}/${key} -> 200 / 404
> > Read entry: GET on ${webPath}/${key}
> > Delete entry: DELETE on ${webPath}/${key}
> >
> > Bye,
> > Daniel
> >
> > 2012/2/19 Simone Tripodi <si...@apache.org>
> >
> >> I am +1 for the Olivier's idea - and I can put my hand on fire nobody
> >> would object it! - anyway at the same time I think Daniel's
> >> consideration really worth - I have a past of RESTer as well :D - I
> >> would go for
> >>
> >> New entry: POST on ${webPath} -> returns 201 with location
> >> Read entry: GET on ${webPath}/${key}
> >> Update entry: PUT on ${webPath}/${key}
> >> Delete entry: DELETE on ${webPath}/${key}
> >>
> >> moreover I'd suggest to avoid managing the stored content in textual
> >> format (it has a cost!), I would proceed for a pure HTTP Content-Type
> >> negotiation:
> >>
> >> application/x-java-serialized-object ->
> >> org.apache.directmemory.serialization.StandardSerializer
> >> application/x-protobuf ->
> >> org.apache.directmemory.serialization.protobuf.ProtobufSerializer
> >> ...
> >> and so on, no real need to jsonize requests/objects, just pure, simple
> >> HTTP.
> >>
> >> +1 for the UI part - actual Archiva UI shows the potentials!
> >>
> >> HTH, all the best,
> >> -Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Sun, Feb 19, 2012 at 8:53 PM, Daniel Manzke
> >> <da...@googlemail.com> wrote:
> >> > Hi,
> >> >
> >> > I could start a REST war now, but I try to be normal. ;)
> >> >
> >> > /{webapp}/directMemory/...
> >> >
> >> > Why do you need "directMemory"? Are there any other implementations?
> >> > "directMemory" can be the webapp name, if you need it, but you should
> not
> >> > use it there.
> >> >
> >> > Why do you need "/store" to simulate methods? You have all you need in
> >> http.
> >> >
> >> > PUT/POST/DELETE
> >> >
> >> > And you are already using it. ;)
> >> >
> >> > I would do it like this:
> >> >
> >> > New entry: PUT on ${webPath} -> returns 201 with location
> >> > Read entry: GET on ${webPath}/${key}
> >> > Update entry: PUT/POST on ${webPath}/${key}
> >> > Delete entry: DELETE on ${webPath}/${key}
> >> >
> >> > If you want some kind of separation because of having a website or
> >> > something else a name for the resource would be fine. (but I wouldn't
> >> call
> >> > it directMemory) Maybe "store" or "cache"?
>
> ${contextPath}/cache/etc... ?
> Yup separation will be needed for ui part.
>
> I will try to push some code early this week.
>
> >> >
> >> > Additionally I would add a name for the cache to the api.
> >> > GET on ${webPath}/${cache}/${key}
> >> >
> >> > So you could have multiple caches for different scenarios.
> >> >
> >> >
> >> > Bye,.
> >> > Daniel
> >> > 2012/2/19 Olivier Lamy <ol...@apache.org>
> >> >
> >> >> Hello Folks,
> >> >>
> >> >> I have started to think/hack around having a server implementation to
> >> >> store object in a direct memory cache (something "à la" memcached).
> >> >>
> >> >> Before discussing about api (fluent or not) having ugly names for
> >> >> methods or not ( :P ).
> >> >> I'd like to share with you my ideas (and get your feedback).
> >> >>
> >> >> Basically I have something in mind to ease users life:
> >> >> * retrieve this object with this key (sync and async methods)
> >> >> * store this object with this key and with this serializer. (sync and
> >> >> async methods)
> >> >> * delete an entry (sync and async methods)
> >> >>
> >> >> The de/serialization is done on client side and exchange are done tru
> >> >> REST (json) over http(s). (Maybe adding later too a "raw" servlet
> with
> >> >> parameters passed as headers)
> >> >>
> >> >> REST Api ideas.
> >> >>
> >> >> retrieve object :
> >> >> GET on ${webPath}/directMemory/retrieve/${key}
> >> >>
> >> >> return json content if found
> >> >>
> >> >> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
> >> >>
> >> >> cacheContent is byte[] from serialization.
> >> >>
> >> >> If no cache entry found for the key, http code returned will be 204
> >> >> (No Content) but client api will receive a DirectMemoryCacheResponse
> >> >> object with found field to false.
> >> >>
> >> >> store object
> >> >>
> >> >> PUT on ${webPath}/directMemory/store
> >> >>
> >> >> json content posted
> >> >>
> >> >>
> >> >>
> >>
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
> >> >>
> >> >> (serializer is for information and if available on server classLoader
> >> >> could be use for a toString in the web ui).
> >> >>
> >> >> delete an entry:
> >> >>
> >> >> DELETE on ${webPath}/directMemory/delete/${key}
> >> >>
> >> >> 200 if ok, 204 if the key was not found.
> >> >>
> >> >> Goodies: the webapp will have an ui to display some figures on cache
> >> >> hit ratio, number of stored elements etc...
> >> >>
> >> >> Let me know if that makes sense and I can start push some hack :-)
> >> >>
> >> >> --
> >> >> Olivier Lamy
> >> >> Talend: http://coders.talend.com
> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> >>
> >> >>
> >> >> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
> >> >> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-)
> ).
> >> >> We hope to see you there :-).
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Viele Grüße/Best Regards
> >> >
> >> > Daniel Manzke
> >>
> >
> >
> >
> > --
> > Viele Grüße/Best Regards
> >
> > Daniel Manzke
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
--
Viele Grüße/Best Regards
Daniel Manzke
Re: [DISCUSS] RFC Server implementation
Posted by Olivier Lamy <ol...@apache.org>.
Agree on suggestion and the raw servlet model.
BTW I don't follow/understand you regarding the Content-Type.
It's just to say the serializer used ? Because Object to cache must be
serialized on client side before going to the server.
2012/2/19 Daniel Manzke <da...@googlemail.com>:
> (after another long discussion with simone ;))
>
> +1 for the content-type idea. I think there should be a server-side
> configuration, where you can map content-type to serializers.
>
> Like mentioned before, I would add a cache "layer" in the path, so you can
> add new caches at runtime. (necessary for cloud env? :))
Why not even if the goal was not really to have more than direct
memory impl on server side :-)
>
> BTW: What comes after the cloud? The sky! :P
>
> New/update entry: PUT on ${webPath}/${key} -> body has the object which
> should be serialized
> Contains entry: HEAD on ${webPath}/${key} -> 200 / 404
> Read entry: GET on ${webPath}/${key}
> Delete entry: DELETE on ${webPath}/${key}
>
> Bye,
> Daniel
>
> 2012/2/19 Simone Tripodi <si...@apache.org>
>
>> I am +1 for the Olivier's idea - and I can put my hand on fire nobody
>> would object it! - anyway at the same time I think Daniel's
>> consideration really worth - I have a past of RESTer as well :D - I
>> would go for
>>
>> New entry: POST on ${webPath} -> returns 201 with location
>> Read entry: GET on ${webPath}/${key}
>> Update entry: PUT on ${webPath}/${key}
>> Delete entry: DELETE on ${webPath}/${key}
>>
>> moreover I'd suggest to avoid managing the stored content in textual
>> format (it has a cost!), I would proceed for a pure HTTP Content-Type
>> negotiation:
>>
>> application/x-java-serialized-object ->
>> org.apache.directmemory.serialization.StandardSerializer
>> application/x-protobuf ->
>> org.apache.directmemory.serialization.protobuf.ProtobufSerializer
>> ...
>> and so on, no real need to jsonize requests/objects, just pure, simple
>> HTTP.
>>
>> +1 for the UI part - actual Archiva UI shows the potentials!
>>
>> HTH, all the best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Feb 19, 2012 at 8:53 PM, Daniel Manzke
>> <da...@googlemail.com> wrote:
>> > Hi,
>> >
>> > I could start a REST war now, but I try to be normal. ;)
>> >
>> > /{webapp}/directMemory/...
>> >
>> > Why do you need "directMemory"? Are there any other implementations?
>> > "directMemory" can be the webapp name, if you need it, but you should not
>> > use it there.
>> >
>> > Why do you need "/store" to simulate methods? You have all you need in
>> http.
>> >
>> > PUT/POST/DELETE
>> >
>> > And you are already using it. ;)
>> >
>> > I would do it like this:
>> >
>> > New entry: PUT on ${webPath} -> returns 201 with location
>> > Read entry: GET on ${webPath}/${key}
>> > Update entry: PUT/POST on ${webPath}/${key}
>> > Delete entry: DELETE on ${webPath}/${key}
>> >
>> > If you want some kind of separation because of having a website or
>> > something else a name for the resource would be fine. (but I wouldn't
>> call
>> > it directMemory) Maybe "store" or "cache"?
${contextPath}/cache/etc... ?
Yup separation will be needed for ui part.
I will try to push some code early this week.
>> >
>> > Additionally I would add a name for the cache to the api.
>> > GET on ${webPath}/${cache}/${key}
>> >
>> > So you could have multiple caches for different scenarios.
>> >
>> >
>> > Bye,.
>> > Daniel
>> > 2012/2/19 Olivier Lamy <ol...@apache.org>
>> >
>> >> Hello Folks,
>> >>
>> >> I have started to think/hack around having a server implementation to
>> >> store object in a direct memory cache (something "à la" memcached).
>> >>
>> >> Before discussing about api (fluent or not) having ugly names for
>> >> methods or not ( :P ).
>> >> I'd like to share with you my ideas (and get your feedback).
>> >>
>> >> Basically I have something in mind to ease users life:
>> >> * retrieve this object with this key (sync and async methods)
>> >> * store this object with this key and with this serializer. (sync and
>> >> async methods)
>> >> * delete an entry (sync and async methods)
>> >>
>> >> The de/serialization is done on client side and exchange are done tru
>> >> REST (json) over http(s). (Maybe adding later too a "raw" servlet with
>> >> parameters passed as headers)
>> >>
>> >> REST Api ideas.
>> >>
>> >> retrieve object :
>> >> GET on ${webPath}/directMemory/retrieve/${key}
>> >>
>> >> return json content if found
>> >>
>> >> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>> >>
>> >> cacheContent is byte[] from serialization.
>> >>
>> >> If no cache entry found for the key, http code returned will be 204
>> >> (No Content) but client api will receive a DirectMemoryCacheResponse
>> >> object with found field to false.
>> >>
>> >> store object
>> >>
>> >> PUT on ${webPath}/directMemory/store
>> >>
>> >> json content posted
>> >>
>> >>
>> >>
>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>> >>
>> >> (serializer is for information and if available on server classLoader
>> >> could be use for a toString in the web ui).
>> >>
>> >> delete an entry:
>> >>
>> >> DELETE on ${webPath}/directMemory/delete/${key}
>> >>
>> >> 200 if ok, 204 if the key was not found.
>> >>
>> >> Goodies: the webapp will have an ui to display some figures on cache
>> >> hit ratio, number of stored elements etc...
>> >>
>> >> Let me know if that makes sense and I can start push some hack :-)
>> >>
>> >> --
>> >> Olivier Lamy
>> >> Talend: http://coders.talend.com
>> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >>
>> >>
>> >> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
>> >> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
>> >> We hope to see you there :-).
>> >>
>> >
>> >
>> >
>> > --
>> > Viele Grüße/Best Regards
>> >
>> > Daniel Manzke
>>
>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSS] RFC Server implementation
Posted by Daniel Manzke <da...@googlemail.com>.
(after another long discussion with simone ;))
+1 for the content-type idea. I think there should be a server-side
configuration, where you can map content-type to serializers.
Like mentioned before, I would add a cache "layer" in the path, so you can
add new caches at runtime. (necessary for cloud env? :))
BTW: What comes after the cloud? The sky! :P
New/update entry: PUT on ${webPath}/${key} -> body has the object which
should be serialized
Contains entry: HEAD on ${webPath}/${key} -> 200 / 404
Read entry: GET on ${webPath}/${key}
Delete entry: DELETE on ${webPath}/${key}
Bye,
Daniel
2012/2/19 Simone Tripodi <si...@apache.org>
> I am +1 for the Olivier's idea - and I can put my hand on fire nobody
> would object it! - anyway at the same time I think Daniel's
> consideration really worth - I have a past of RESTer as well :D - I
> would go for
>
> New entry: POST on ${webPath} -> returns 201 with location
> Read entry: GET on ${webPath}/${key}
> Update entry: PUT on ${webPath}/${key}
> Delete entry: DELETE on ${webPath}/${key}
>
> moreover I'd suggest to avoid managing the stored content in textual
> format (it has a cost!), I would proceed for a pure HTTP Content-Type
> negotiation:
>
> application/x-java-serialized-object ->
> org.apache.directmemory.serialization.StandardSerializer
> application/x-protobuf ->
> org.apache.directmemory.serialization.protobuf.ProtobufSerializer
> ...
> and so on, no real need to jsonize requests/objects, just pure, simple
> HTTP.
>
> +1 for the UI part - actual Archiva UI shows the potentials!
>
> HTH, all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Feb 19, 2012 at 8:53 PM, Daniel Manzke
> <da...@googlemail.com> wrote:
> > Hi,
> >
> > I could start a REST war now, but I try to be normal. ;)
> >
> > /{webapp}/directMemory/...
> >
> > Why do you need "directMemory"? Are there any other implementations?
> > "directMemory" can be the webapp name, if you need it, but you should not
> > use it there.
> >
> > Why do you need "/store" to simulate methods? You have all you need in
> http.
> >
> > PUT/POST/DELETE
> >
> > And you are already using it. ;)
> >
> > I would do it like this:
> >
> > New entry: PUT on ${webPath} -> returns 201 with location
> > Read entry: GET on ${webPath}/${key}
> > Update entry: PUT/POST on ${webPath}/${key}
> > Delete entry: DELETE on ${webPath}/${key}
> >
> > If you want some kind of separation because of having a website or
> > something else a name for the resource would be fine. (but I wouldn't
> call
> > it directMemory) Maybe "store" or "cache"?
> >
> > Additionally I would add a name for the cache to the api.
> > GET on ${webPath}/${cache}/${key}
> >
> > So you could have multiple caches for different scenarios.
> >
> >
> > Bye,.
> > Daniel
> > 2012/2/19 Olivier Lamy <ol...@apache.org>
> >
> >> Hello Folks,
> >>
> >> I have started to think/hack around having a server implementation to
> >> store object in a direct memory cache (something "à la" memcached).
> >>
> >> Before discussing about api (fluent or not) having ugly names for
> >> methods or not ( :P ).
> >> I'd like to share with you my ideas (and get your feedback).
> >>
> >> Basically I have something in mind to ease users life:
> >> * retrieve this object with this key (sync and async methods)
> >> * store this object with this key and with this serializer. (sync and
> >> async methods)
> >> * delete an entry (sync and async methods)
> >>
> >> The de/serialization is done on client side and exchange are done tru
> >> REST (json) over http(s). (Maybe adding later too a "raw" servlet with
> >> parameters passed as headers)
> >>
> >> REST Api ideas.
> >>
> >> retrieve object :
> >> GET on ${webPath}/directMemory/retrieve/${key}
> >>
> >> return json content if found
> >>
> >> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
> >>
> >> cacheContent is byte[] from serialization.
> >>
> >> If no cache entry found for the key, http code returned will be 204
> >> (No Content) but client api will receive a DirectMemoryCacheResponse
> >> object with found field to false.
> >>
> >> store object
> >>
> >> PUT on ${webPath}/directMemory/store
> >>
> >> json content posted
> >>
> >>
> >>
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
> >>
> >> (serializer is for information and if available on server classLoader
> >> could be use for a toString in the web ui).
> >>
> >> delete an entry:
> >>
> >> DELETE on ${webPath}/directMemory/delete/${key}
> >>
> >> 200 if ok, 204 if the key was not found.
> >>
> >> Goodies: the webapp will have an ui to display some figures on cache
> >> hit ratio, number of stored elements etc...
> >>
> >> Let me know if that makes sense and I can start push some hack :-)
> >>
> >> --
> >> Olivier Lamy
> >> Talend: http://coders.talend.com
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >>
> >> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
> >> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
> >> We hope to see you there :-).
> >>
> >
> >
> >
> > --
> > Viele Grüße/Best Regards
> >
> > Daniel Manzke
>
--
Viele Grüße/Best Regards
Daniel Manzke
Re: [DISCUSS] RFC Server implementation
Posted by Simone Tripodi <si...@apache.org>.
I am +1 for the Olivier's idea - and I can put my hand on fire nobody
would object it! - anyway at the same time I think Daniel's
consideration really worth - I have a past of RESTer as well :D - I
would go for
New entry: POST on ${webPath} -> returns 201 with location
Read entry: GET on ${webPath}/${key}
Update entry: PUT on ${webPath}/${key}
Delete entry: DELETE on ${webPath}/${key}
moreover I'd suggest to avoid managing the stored content in textual
format (it has a cost!), I would proceed for a pure HTTP Content-Type
negotiation:
application/x-java-serialized-object ->
org.apache.directmemory.serialization.StandardSerializer
application/x-protobuf ->
org.apache.directmemory.serialization.protobuf.ProtobufSerializer
...
and so on, no real need to jsonize requests/objects, just pure, simple HTTP.
+1 for the UI part - actual Archiva UI shows the potentials!
HTH, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Feb 19, 2012 at 8:53 PM, Daniel Manzke
<da...@googlemail.com> wrote:
> Hi,
>
> I could start a REST war now, but I try to be normal. ;)
>
> /{webapp}/directMemory/...
>
> Why do you need "directMemory"? Are there any other implementations?
> "directMemory" can be the webapp name, if you need it, but you should not
> use it there.
>
> Why do you need "/store" to simulate methods? You have all you need in http.
>
> PUT/POST/DELETE
>
> And you are already using it. ;)
>
> I would do it like this:
>
> New entry: PUT on ${webPath} -> returns 201 with location
> Read entry: GET on ${webPath}/${key}
> Update entry: PUT/POST on ${webPath}/${key}
> Delete entry: DELETE on ${webPath}/${key}
>
> If you want some kind of separation because of having a website or
> something else a name for the resource would be fine. (but I wouldn't call
> it directMemory) Maybe "store" or "cache"?
>
> Additionally I would add a name for the cache to the api.
> GET on ${webPath}/${cache}/${key}
>
> So you could have multiple caches for different scenarios.
>
>
> Bye,.
> Daniel
> 2012/2/19 Olivier Lamy <ol...@apache.org>
>
>> Hello Folks,
>>
>> I have started to think/hack around having a server implementation to
>> store object in a direct memory cache (something "à la" memcached).
>>
>> Before discussing about api (fluent or not) having ugly names for
>> methods or not ( :P ).
>> I'd like to share with you my ideas (and get your feedback).
>>
>> Basically I have something in mind to ease users life:
>> * retrieve this object with this key (sync and async methods)
>> * store this object with this key and with this serializer. (sync and
>> async methods)
>> * delete an entry (sync and async methods)
>>
>> The de/serialization is done on client side and exchange are done tru
>> REST (json) over http(s). (Maybe adding later too a "raw" servlet with
>> parameters passed as headers)
>>
>> REST Api ideas.
>>
>> retrieve object :
>> GET on ${webPath}/directMemory/retrieve/${key}
>>
>> return json content if found
>>
>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>>
>> cacheContent is byte[] from serialization.
>>
>> If no cache entry found for the key, http code returned will be 204
>> (No Content) but client api will receive a DirectMemoryCacheResponse
>> object with found field to false.
>>
>> store object
>>
>> PUT on ${webPath}/directMemory/store
>>
>> json content posted
>>
>>
>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>>
>> (serializer is for information and if available on server classLoader
>> could be use for a toString in the web ui).
>>
>> delete an entry:
>>
>> DELETE on ${webPath}/directMemory/delete/${key}
>>
>> 200 if ok, 204 if the key was not found.
>>
>> Goodies: the webapp will have an ui to display some figures on cache
>> hit ratio, number of stored elements etc...
>>
>> Let me know if that makes sense and I can start push some hack :-)
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
>> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
>> We hope to see you there :-).
>>
>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke
Re: [DISCUSS] RFC Server implementation
Posted by Daniel Manzke <da...@googlemail.com>.
Hi,
I could start a REST war now, but I try to be normal. ;)
/{webapp}/directMemory/...
Why do you need "directMemory"? Are there any other implementations?
"directMemory" can be the webapp name, if you need it, but you should not
use it there.
Why do you need "/store" to simulate methods? You have all you need in http.
PUT/POST/DELETE
And you are already using it. ;)
I would do it like this:
New entry: PUT on ${webPath} -> returns 201 with location
Read entry: GET on ${webPath}/${key}
Update entry: PUT/POST on ${webPath}/${key}
Delete entry: DELETE on ${webPath}/${key}
If you want some kind of separation because of having a website or
something else a name for the resource would be fine. (but I wouldn't call
it directMemory) Maybe "store" or "cache"?
Additionally I would add a name for the cache to the api.
GET on ${webPath}/${cache}/${key}
So you could have multiple caches for different scenarios.
Bye,.
Daniel
2012/2/19 Olivier Lamy <ol...@apache.org>
> Hello Folks,
>
> I have started to think/hack around having a server implementation to
> store object in a direct memory cache (something "à la" memcached).
>
> Before discussing about api (fluent or not) having ugly names for
> methods or not ( :P ).
> I'd like to share with you my ideas (and get your feedback).
>
> Basically I have something in mind to ease users life:
> * retrieve this object with this key (sync and async methods)
> * store this object with this key and with this serializer. (sync and
> async methods)
> * delete an entry (sync and async methods)
>
> The de/serialization is done on client side and exchange are done tru
> REST (json) over http(s). (Maybe adding later too a "raw" servlet with
> parameters passed as headers)
>
> REST Api ideas.
>
> retrieve object :
> GET on ${webPath}/directMemory/retrieve/${key}
>
> return json content if found
>
> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
>
> cacheContent is byte[] from serialization.
>
> If no cache entry found for the key, http code returned will be 204
> (No Content) but client api will receive a DirectMemoryCacheResponse
> object with found field to false.
>
> store object
>
> PUT on ${webPath}/directMemory/store
>
> json content posted
>
>
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
>
> (serializer is for information and if available on server classLoader
> could be use for a toString in the web ui).
>
> delete an entry:
>
> DELETE on ${webPath}/directMemory/delete/${key}
>
> 200 if ok, 204 if the key was not found.
>
> Goodies: the webapp will have an ui to display some figures on cache
> hit ratio, number of stored elements etc...
>
> Let me know if that makes sense and I can start push some hack :-)
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
> We hope to see you there :-).
>
--
Viele Grüße/Best Regards
Daniel Manzke