incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [DISCUSS] RFC Server implementation
Date Mon, 20 Feb 2012 08:31:27 GMT
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 <olamy@apache.org> wrote:
> Agree on suggestion and the raw servlet model.

>
> 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