Salut Benoit, +1 for the regions - it is something I called "namespaces" in the early DM days, full support from my side for it.
+0 for the serializer - same cache/region _could_ be accessed bu different clients using different serialization, anyway +1 for the region properties. can you please share more devoxx details please? I could come to Paris! 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 11:53 AM, Benoit Perroud <[email protected]> wrote: > Hi All, > > First of all thanks for the warm welcome of the presentation, we'll > try to spread the word as much as possible. > > My idea here would be to have several "cache region", like > > ${webPath}/${region}/${key} > > and allowing some metadata regarding those regions : > > - The serializer (thus no need to pass it at every request) > - Properties of the region : max size, eviction algorithm, slab size > (if my new implementation will be selected), ... > > Objects of the same nature could be stored in the same "region". > > From the actual code base, there is some synchronization done to > allocate object in a Cache, thus having multiple region/caches in the > back would allow more concurrency. And would be able to fine tune the > cache for the objects stored (big almost static files vs small often > changing objects). > > Cheers, > > Benoit. > > > > > 2012/2/20 Simone Tripodi <[email protected]>: >> Salut! >> >>> BTW nothing prevent to have both implementations (based on >>> Content-Type "application/json;charset=UTF-8" for json model exchange >>> :-) ) >> >> sure, that is why I like content type negotiation: same URI, different >> way to exchange content. Simple & cool at the same time :P >> >>> Doh sure we can "win" some packet on network layer :-) >>> >> >> lol, aren't we problem solvers? :D >> >>> Ok I will start as it. My first impl (push) will be with json exchange >>> as I have it locally :-). >>> >>> Then I will improve with the "raw" model based on Content-Type and http >>> headers. >> >> looking forward to read the code, hope to be helpful! >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Mon, Feb 20, 2012 at 11:01 AM, Olivier Lamy <[email protected]> wrote: >>> 2012/2/20 Simone Tripodi <[email protected]>: >>>> Salut! >>>> >>>> I see we have 2 different use cases in mind, that is why we are not in >>>> sync. >>>> >>>> I personally see that adopting your APIs layer, for each request, body >>>> content has to be serialized in a textual form - no matter how fast it >>>> is, that means that both client/server need to (de)serialize the >>>> content. >>> >>>> >>>> The client builds the request -> serialize it in JSON -> creates the >>>> JSON request -> send it to the server -> the server extract the JSON >>>> content -> stream it in the memory. >>> agree it can be a performance "problem". >>> >> >>> >>>> >>>> Let's explore more possibilities: you can still map your JSON request >>>> model to pure HTTP protocol: >>>> >>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a >>>> json/xml string* >>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >>>> >>>> would become >>>> >>>> +----+ >>>> PUT ${webPath}/${key} >>>> Content-Type: text/xml >>> I would prefer use an other Content-Type IMHO >>> "application/x-java-serialized-object" was a good idea. >>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT >>>> >>>> serialized-body >>>> +----+ >>>> >>>> extra non-standard fields can be added via the X- prefix, for example, >>>> the preference of used serializer to store the content: >>> Good idea. >>>> >>>> +----+ >>>> PUT ${webPath}/${key} >>>> Content-Type: text/xml >>>> Expires: Thu, 01 Dec 2012 16:00:00 GMT >>>> X-DirectMemory-Serializer: >>>> org.apache.directmemory.serialization.StandardSerializer >>>> >>>> serialized-body >>>> +----+ >>>> >>>> You should still be able to write the JS httpclient to interact with >>>> the server - it is just HTTP! - without paying the overhead of more >>>> parsing operations. >>>> >>>> Moreover, if you'll proceed to JSON, I think that the proposed format >>>> can be thiner: >>>> >>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a >>>> json/xml string* >>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >>>> >>>> could be >>>> >>>> {"key":"101","expiresIn":123,"cacheContent":"*here a >>>> json/xml string* >>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"} >>>> >>>> dropping the DirectMemoryRQ container (it is yet another data structure :P) >>> >>> Doh sure we can "win" some packet on network layer :-) >>> >>> Ok I will start as it. My first impl (push) will be with json exchange >>> as I have it locally :-). >>> >>> Then I will improve with the "raw" model based on Content-Type and http >>> headers. >>> >>>> >>>> Thanks for brainstorming! >>> >>> You're welcome :P >>> >>>> -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:55 AM, Olivier Lamy <[email protected]> wrote: >>>>> Hello, >>>>> >>>>> 2012/2/20 Simone Tripodi <[email protected]>: >>>>>>> Hmmmm. Simone should answer this. >>>>>>> >>>>>>> If I'm really thinking about it, the content-type makes no sense. ;) >>>>>> >>>>>> it does instead, because the server has to be able to reply the >>>>>> serialization content type when clients ask for stored - or you expect >>>>>> the client automagically understands it? Or you expect to have just >>>>>> one client type per application, so the serialization type is always >>>>>> the same? Couldn't servers be populated by heterogeneous clients that >>>>>> read each other data? >>>>> The client will be responsible for de/serialization. >>>>> My preference for more "complex" content is for new feature and >>>>> enhance cache request/response with new field. >>>>> >>>>> retrieve object : >>>>> GET on ${webPath}/cache/${key} >>>>> >>>>> return json content if found >>>>> >>>>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}} >>>>> Using this format we will be able to add new fields in the ison >>>>> "object" (cacheAge etc...) >>>>> >>>>> PUT on ${webPath}/cache >>>>> >>>>> json content posted >>>>> >>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >>>>> >>>>> Again using a json "object" we will be able to easily add new "fields". >>>>> >>>>> Why using json I have in mind using cache access directly tru a >>>>> javascript application with something like : >>>>> >>>>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a >>>>> json/xml string* >>>>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >>>>> >>>>> As it the server we will be able to serialize then store the json/xml >>>>> content. >>>>> And you can use directly from your javascript application. >>>>> >>>>> Compare to an Api. >>>>> >>>>> wineService.findWine(year, name) >>>>> >>>>> wineService.find(wineSearchRequest) >>>>> >>>>> With >>>>> WineSearchRequest { >>>>> year; >>>>> name; >>>>> } >>>>> >>>>> I tend to prefer using the second pattern as it's more easy to improve >>>>> the model without breaking (normally :-) ) the backward comp. >>>>> >>>>> Makes sense ? >>>>> >>>>>> >>>>>> "makes no sense" is a hard assertion, I always think more than twice >>>>>> before saying that ;) >>>>>> >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://simonetripodi.livejournal.com/ >>>>>> http://twitter.com/simonetripodi >>>>>> http://www.99soft.org/ >>>>> >>>>> >>>>> >>>>> -- >>>>> Olivier Lamy >>>>> Talend: http://coders.talend.com >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> >>> >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > -- > sent from my Nokia 3210
