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 <[email protected]> > 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 <[email protected]>: > > (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 <[email protected]> > > > >> 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 > >> <[email protected]> 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 <[email protected]> > >> > > >> >> 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
