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 23:35:09 GMT
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 <olamy@apache.org>

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



-- 
Viele Grüße/Best Regards

Daniel Manzke

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