incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Manzke <daniel.man...@googlemail.com>
Subject Re: [DISCUSS] RFC Server implementation
Date Sun, 19 Feb 2012 21:33:59 GMT
(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 <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"?
> >
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message