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:41:32 GMT
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
<simonetripodi@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 <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