Salut! a part that the request you described in some cases replies 400 Bad Request ;) , text/plain is fine :)
if you already have in mind an XML format for describing the server config, I would be glad to plug quickly the digester :) 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 3:04 PM, Olivier Lamy <[email protected]> wrote: > Yup for region but what about having a fix uri ? > And adding that in a http header or new field in the json request ? > > @Simone > Regarding raw plain text mode, I would prefer something content type > text/plain like (a real sample below :P ) > > PUT PUT ${webPath}/the truth > Content-Type: text/plain > Expires: Thu, 01 Dec 2099 16:00:00 GMT > X-DirectMemory-Serializer: > org.apache.directmemory.serialization.StandardSerializer > French Wine is better than Italian Wine. > > > Something else I have in mind is the server configuration. > My current impl (as it can be improved easily later) is System > Property based and only one cache/region. > > // TODO some configuration for cacheService.init( .... ); > different from sysproperties > //int numberOfBuffers, int size, int initialCapacity, int > concurrencyLevel > int numberOfBuffers = Integer.getInteger( > "directMemory.numberOfBuffers", 1000 ); > int size = Integer.getInteger( "directMemory.size", 10 ); > int initialCapacity = > Integer.getInteger( "directMemory.initialCapacity", > CacheService.DEFAULT_INITIAL_CAPACITY ); > int concurrencyLevel = > Integer.getInteger( "directMemory.concurrencyLevel", > CacheService.DEFAULT_CONCURRENCY_LEVEL ); > cacheService.init( numberOfBuffers, size, initialCapacity, > concurrencyLevel ); > > What about a xml configuration file (maybe using digester :-) )? > > > 2012/2/20 Benoit Perroud <[email protected]>: >> 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 > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy
