incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: [DISCUSS] RFC Server implementation
Date Sun, 19 Feb 2012 23:28:35 GMT
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 <daniel.manzke@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 <simonetripodi@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
>> <daniel.manzke@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 <olamy@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

Mime
View raw message