OK let's keep them out then Il giorno 30/set/2012 10:26, "Noctarius" <[email protected]> ha scritto:
> Hey it's me again ;-) > > There are at least two files that are not AL2 licensed but can be > used (I think). > > > https://github.com/noctarius/Lightning/tree/master/lightning-core/src/main/java/com/github/lightning/internal/instantiator/jrockit > > If it's not possible to leave them in the sourcetree I'm pretty sure > there will be no problem when we remove them since they are used for > older JRocket versions. > > Am 29.09.2012 21:05, schrieb Raffaele P. Guidi: > > I kinda suspected that... > > Il giorno 29/set/2012 20:47, "Noctarius" <[email protected]> ha scritto: > > > >> Actually all dependencies should be AL2 or BSD licensed :-) > >> > >> Am 29.09.2012 20:42, schrieb Raffaele P. Guidi: > >>>>> Hehe well that really sounds like a nice bunch of people. > >>> > >>> Indeed they are (I'm a newbie as well and try to do my best) > >>> > >>>>> If lightning will be a sub-part (sub-project) of DM, do I > >>>>> need to write > >>> an project purposal? > >>> > >>> Nope, not needed for a sub-project > >>> > >>>>> Do I need to make any changes to the pom.xml like adding a > >>> special parent pom or anything like that? > >>> > >>> Not for the serializer - just have to take a look at project > >>> dependencies - or, better, at their licenses - are they > >>> compatible with the ASL 2.0? i.e. a GPL'd library is not a good > >>> fit and should be replaced with an apache licensed (or BSD, or > >>> MIT...) one if possible. For the integration module is a > >>> separate story - you should start off copying one of the other > >>> serializers and reusing the same pom and directory structure. > >>> > >>> Pleased to meet you, Chris :) > >>> > >>> Ciao, R > >>> > >>> On Sat, Sep 29, 2012 at 8:24 PM, Noctarius <[email protected]> > >>> wrote: > >>> > >>>> Hehe well that really sounds like a nice bunch of people. > >>>> > >>>> Ok to be true I couldn't wait until tomorrow and started > >>>> already reading the links. From what I was reading: If > >>>> lightning will be a sub-part (sub-project) of DM, do I need > >>>> to write an project purposal? > >>>> > >>>> Do I need to make any changes to the pom.xml like adding a > >>>> special parent pom or anything like that? > >>>> > >>>> In general: there are a lot things to know :-) > >>>> > >>>> Am 29.09.2012 19:59, schrieb Raffaele P. Guidi: > >>>>> Negative part of ASF membership? You get together with a > >>>>> lot of geeky, talented people with a fixation for software > >>>>> and open source. Oh wait but this is actually nice! :-D Il > >>>>> giorno 29/set/2012 19:05, "Olivier Lamy" <[email protected]> > >>>>> ha > >>>> scritto: > >>>>> > >>>>>> 2012/9/29 Noctarius <[email protected]>: > >>>>>>> Thanks Olivier for carify, I'll take a look in it > >>>>>>> tomorrow but there's just one question left (for now > >>>>>>> ;)): What is that vote for becoming a committer? What > >>>>>>> if the vote will be negative? > >>>>>> The vote is on private list (pmc list for privacy reasons > >>>>>> and possible negative stuff being on public lists) > >>>>>>> Until now I just used Apache stuff, was never > >>>>>>> interested in being part of it so I guess it can be > >>>>>>> negative for any reason, can't it? > >>>>>> I don't see why it could be negative but suspens .... > >>>>>> :-) > >>>>>>> > >>>>>>> Am 29.09.2012 18:56, schrieb Olivier Lamy: > >>>>>>>> 2012/9/29 Noctarius <[email protected]>: > >>>>>>>>> Nope my real name is Christoph Engelbert, but > >>>>>>>>> Noctarius is the all time nick :) > >>>>>>>>> > >>>>>>>>> Renaming the package should be no problem, is it > >>>>>>>>> "org.apache.directmemory.lightning" or what would > >>>>>>>>> it be? > >>>>>>>> fine for me > >>>>>>>>> Then there needs to be a change in the license > >>>>>>>>> header as Olivier mentioned, that means just remove > >>>>>>>>> the first sentence or is there anything more to do > >>>>>>>>> (maybe it's easiest thing to just copy the header > >>>>>>>>> from DM file ;))? > >>>>>>>> yup use same header as DM > >>>>>>>>> > >>>>>>>>> The CLA is just a form to clarify that the source > >>>>>>>>> can be contributed to the Apache Foundation? > >>>>>>>> yup correct. > >>>>>>>>> > >>>>>>>>> The final step will be attaching the patch in form > >>>>>>>>> of a huge diff file? > >>>>>>>> yes > >>>>>>>>> > >>>>>>>>> And what is the way to apply for a membership? > >>>>>>>>> Never thought about how to do that. > >>>>>>>> Read here > >>>>>>>> http://apache.org/foundation/how-it-works.html and > >>>>>>>> here http://apache.org/foundation/getinvolved.html . > >>>>>>>> And feel free to ask any questions :-) > >>>>>>>>> > >>>>>>>>> Chris > >>>>>>>>> > >>>>>>>>> Am 29.09.2012 18:23, schrieb Raffaele P. Guidi: > >>>>>>>>>> OK, deal, at least for me ;-) I propose you > >>>>>>>>>> rename the packages, produce a patch for this and > >>>>>>>>>> the new serializer module (should be simple > >>>>>>>>>> enough starting from an existing one) and, in the > >>>>>>>>>> meanwhile, apply for ASF membership. Is IP > >>>>>>>>>> clearance needed? I guess yes. After this we will > >>>>>>>>>> come up with a formal vote regarding Noctarius > >>>>>>>>>> (is this your real name?!) allowance in the > >>>>>>>>>> project team. > >>>>>>>>>> > >>>>>>>>>> Good times are gonna come :-) > >>>>>>>>>> > >>>>>>>>>> Thanks, R Il giorno 29/set/2012 17:58, "Olivier > >>>>>>>>>> Lamy" <[email protected]> ha scritto: > >>>>>>>>>> > >>>>>>>>>>> 2012/9/29 Raffaele P. Guidi > >>>>>>>>>>> <[email protected]>: > >>>>>>>>>>>> Well we already have a NIO ready interface > >>>>>>>>>>>> allowing direct access to DMs managed > >>>>>>>>>>>> bytebuffers but I think this is just half way > >>>>>>>>>>>> to what could be achieved optimally blending > >>>>>>>>>>>> serialization and memory allocation > >>>>>>>>>>>> together. > >>>>>>>>>>>> > >>>>>>>>>>>> Lightning as a module is of course a good > >>>>>>>>>>>> idea and it could easily evolve as a > >>>>>>>>>>>> subproject (for the more experienced asf > >>>>>>>>>>>> members: is it a feasible way?). > >>>>>>>>>>> Nothing prevent to have > >>>>>>>>>>> http://svn.apache.org/repos/asf/directmemory/lightning/trunk > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> > >>>>>>>>>>> > >> with a package like: o.a.d.lightning That will be a > >>>>>>>>>>> subproject. > >>>>>>>>>>>> > >>>>>>>>>>>> Ciao, R Il giorno 29/set/2012 17:44, > >>>>>>>>>>>> "Noctarius" <[email protected]> ha scritto: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hey guys, > >>>>>>>>>>>>> > >>>>>>>>>>>>> ok there's no lightning binary available > >>>>>>>>>>>>> since lightning wasn't ready yet for > >>>>>>>>>>>>> releasing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> For being the only developer it would be no > >>>>>>>>>>>>> problem to contribute the sourcebase for > >>>>>>>>>>>>> DirectMemory but I'm not sure yet if it > >>>>>>>>>>>>> wouldn't be better to seperate it to be > >>>>>>>>>>>>> available without using DirectMemory > >>>>>>>>>>>>> itself. I started it as a serializer for > >>>>>>>>>>>>> cluster synchronization, but it would be > >>>>>>>>>>>>> cool to contribute lightning as a > >>>>>>>>>>>>> subproject to DirectMemory :-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> About the second project I would love to > >>>>>>>>>>>>> see a public available buffer API directly > >>>>>>>>>>>>> in DirectMemory so that project would be > >>>>>>>>>>>>> nearly needless :-) The only difference I > >>>>>>>>>>>>> think is the allocation strategy my > >>>>>>>>>>>>> implementation is using against the one > >>>>>>>>>>>>> DirectMemory has, but I'm pretty sure the > >>>>>>>>>>>>> allocation is extensible ;-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Like I said, for both projects I'm the only > >>>>>>>>>>>>> dev so there would be no IP problem. So if > >>>>>>>>>>>>> it's ok to you to not include lightning > >>>>>>>>>>>>> directly in DM I would be glad to > >>>>>>>>>>>>> contribute to the Apache Foundation :-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cheers Chris > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Am 29.09.2012 16:53, schrieb Raffaele P. > >>>>>>>>>>>>> Guidi: > >>>>>>>>>>>>>> Ok so it's up to noctarius - your move! > >>>>>>>>>>>>>> ;-) Regarding the new unsafe storage: > >>>>>>>>>>>>>> it's an opt-in feature that can be set > >>>>>>>>>>>>>> with the fluent API > >>>>>>>>>>> (and > >>>>>>>>>>>>>> soon through the conference file). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Ciao, R Il giorno 29/set/2012 16:45, > >>>>>>>>>>>>>> "Olivier Lamy" <[email protected]> ha > >>>>>>>>>>>>> scritto: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2012/9/29 Raffaele P. Guidi > >>>>>>>>>>>>>>> <[email protected]>: > >>>>>>>>>>>>>>>>>> At least for the moment he can > >>>>>>>>>>>>>>>>>> provide a patch to be integrated > >>>>>>>>>>> in DM > >>>>>>>>>>>>>>> :-) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Sure, but as lightning is not in any > >>>>>>>>>>>>>>>> public mvn repo should its > >>>>>>>>>>> code be > >>>>>>>>>>>>>>>> re-published in our svn? Or what? > >>>>>>>>>>>>>>> @Apache we don't care about binaries, > >>>>>>>>>>>>>>> only sources are important ! (a bit > >>>>>>>>>>>>>>> theorical for sure but that's it :-) ). > >>>>>>>>>>>>>>> So if Noctarius was the only guy who > >>>>>>>>>>>>>>> participate in lightning. He can just > >>>>>>>>>>>>>>> provide a patch we could integrate as a > >>>>>>>>>>>>>>> new dm module (note: the patch must not > >>>>>>>>>>>>>>> contains any more copyright and all > >>>>>>>>>>>>>>> sources must have ASF licenses). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> "Copyright 2012 the original author or > >>>>>>>>>>>>>>> authors." must be removed. And BTW > >>>>>>>>>>>>>>> package must be changed :-) (com.github > >>>>>>>>>>>>>>> is not acceptable > >>>>>>>>>>> @asf > >>>>>>>>>>>>>>> :-) )(@Noctarius are you working for > >>>>>>>>>>>>>>> github ? :-) ) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> And having him as a committer will be > >>>>>>>>>>>>>>> only a matter of voting (we > >>>>>>>>>>> have > >>>>>>>>>>>>>>> a great chair who take cares of > >>>>>>>>>>>>>>> administrative stuff :P ) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> If some others have participated in the > >>>>>>>>>>>>>>> project, we must pass tru an ip > >>>>>>>>>>>>>>> clearance mechanism > >>>>>>>>>>>>>>> (http://incubator.apache.org/ip-clearance/index.html) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>>>>> > >> and all contributors to lightning must provide a cla. > >>>>>>>>>>>>>>> (It it's the case I can help) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> perso I'd like we avoid hard > >>>>>>>>>>>>>>>>>> dependency on Unsafe as maybe > >>>>>>>>>>>>>>>>>> some > >>>>>>>>>>> use > >>>>>>>>>>>>>>>> other jdks :-) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Well, I believe Unsafe is supported > >>>>>>>>>>>>>>>> by Sun JDK, OpenJDK, IBM JDK and > >>>>>>>>>>>>>>>> JRockit - and I believe that it is > >>>>>>>>>>>>>>>> more than enough. Also keep in > >>>>>>>>>>> mind > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>> we already have an alternative Unsafe > >>>>>>>>>>>>>>>> based memory storage - and > >>>>>>>>>>>>> although > >>>>>>>>>>>>>>>> it's not thoroughly tested for > >>>>>>>>>>>>>>>> performance it dramaticaly > >>>>>>>>>>>>>>>> simplifies > >>>>>>>>>>>>>>> code, > >>>>>>>>>>>>>>>> I have great expectations about it. > >>>>>>>>>>>>>>> Me too :-). Yup definitely more simple > >>>>>>>>>>>>>>> and faster ! But we must provide a > >>>>>>>>>>>>>>> switch off configuration mechanism if > >>>>>>>>>>>>>>> some > >>>>>>>>>>> users > >>>>>>>>>>>>>>> don't want to use that (because Unsafe > >>>>>>>>>>>>>>> is just "Unsafe" :-) ) And sorry I > >>>>>>>>>>>>>>> didn't have a look yet at your changes > >>>>>>>>>>>>>>> with using Unsafe. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Cheers, R > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Sat, Sep 29, 2012 at 4:03 PM, > >>>>>>>>>>>>>>>> Olivier Lamy <[email protected]> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 2012/9/29 Raffaele P. Guidi > >>>>>>>>>>>>>>>>> <[email protected]>: > >>>>>>>>>>>>>>>>>> What do you think about: 1) > >>>>>>>>>>>>>>>>>> implementing a lightning > >>>>>>>>>>>>>>>>>> serialization module 2) creating > >>>>>>>>>>>>>>>>>> a serializer that directly works > >>>>>>>>>>>>>>>>>> on a directmemory > >>>>>>>>>>>>>>> provider > >>>>>>>>>>>>>>>>>> ByteBuffer or (maybe better) > >>>>>>>>>>>>>>>>>> Unsafe based Pointer? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Sounds good (perso I'd like we > >>>>>>>>>>>>>>>>> avoid hard dependency on Unsafe as > >>>>>>>>>>>>>>>>> maybe some use other jdks :-) ) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Now I see lightning is apache > >>>>>>>>>>>>>>>>>> licensed and this is fine but I > >>>>>>>>>>> don't > >>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>> it is published in any public > >>>>>>>>>>>>>>>>>> maven repo, am I right? We could > >>>>>>>>>>> find a > >>>>>>>>>>>>>>> way > >>>>>>>>>>>>>>>>>> to deal with this; options vary > >>>>>>>>>>>>>>>>>> from publishing lightning to the > >>>>>>>>>>> free > >>>>>>>>>>>>>>>>>> sonatype repo, joining the ASF > >>>>>>>>>>>>>>>>>> (which is great anyhow!) and > >>>>>>>>>>>>>>> republishing > >>>>>>>>>>>>>>>>>> lightning code in DirectMemory > >>>>>>>>>>>>>>>>>> becoming a commiter (which has > >>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>> undergo > >>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>> PMC vote). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> At least for the moment he can > >>>>>>>>>>>>>>>>> provide a patch to be integrated > >>>>>>>>>>>>>>>>> in > >>>>>>>>>>> DM > >>>>>>>>>>>>>>> :-) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I'd like to hear your and the > >>>>>>>>>>>>>>>>>> team feelings on this. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks, Raffaele > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Sat, Sep 29, 2012 at 3:27 PM, > >>>>>>>>>>>>>>>>>> Noctarius <[email protected]> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hey Raffaele, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> that's quite similar to what I > >>>>>>>>>>>>>>>>>>> did at work. We're developing > >>>>>>>>>>> Flash > >>>>>>>>>>>>>>>>>>> online games and using a > >>>>>>>>>>>>>>>>>>> customized AMF serialization. > >>>>>>>>>>>>>>>>>>> To support async writing of the > >>>>>>>>>>>>>>>>>>> clients event results I added > >>>>>>>>>>>>>>>>>>> serialization > >>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>> the components / entities to > >>>>>>>>>>>>>>>>>>> the players zone calculation > >>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>> stored > >>>>>>>>>>>>>>>>>>> the pre-serialized bytestream > >>>>>>>>>>>>>>>>>>> directly to the off-heap (using > >>>>>>>>>>>>>>>>>>> direct-ring-cache > >>>>>>>>>>>>>>>>>>> implementation). When the > >>>>>>>>>>>>>>>>>>> client requests the results > >>>>>>>>>>>>>>>>>>> (using long-polling) I just > >>>>>>>>>>>>>>>>>>> write the pre-serialized > >>>>>>>>>>> data to > >>>>>>>>>>>>>>>>>>> the right position to > >>>>>>>>>>>>>>>>>>> deserialize it by standard ways > >>>>>>>>>>>>>>>>>>> on Flash > >>>>>>>>>>> side. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> So yeah an seriliaztion to > >>>>>>>>>>>>>>>>>>> off-heap algorithm would be > >>>>>>>>>>>>>>>>>>> fine. You > >>>>>>>>>>> can > >>>>>>>>>>>>>>>>>>> avoid using byte arrays and > >>>>>>>>>>>>>>>>>>> minimalize GC. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Cheers Chris > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Am 29.09.2012 15:02, schrieb > >>>>>>>>>>>>>>>>>>> Raffaele P. Guidi: > >>>>>>>>>>>>>>>>>>>> Nice to hear back from you! > >>>>>>>>>>>>>>>>>>>> Yes, I was thinking about > >>>>>>>>>>>>>>>>>>>> creating a > >>>>>>>>>>>>>>> new > >>>>>>>>>>>>>>>>>>> memory > >>>>>>>>>>>>>>>>>>>> storage implementation using > >>>>>>>>>>>>>>>>>>>> Unsafe (and I did it, > >>>>>>>>>>>>>>>>>>>> recently) and > >>>>>>>>>>>>>>>>> also, as > >>>>>>>>>>>>>>>>>>>> DirectMemory relies heavily > >>>>>>>>>>>>>>>>>>>> on serialization (and > >>>>>>>>>>>>>>>>>>>> supports many > >>>>>>>>>>> of > >>>>>>>>>>>>>>>>> them, > >>>>>>>>>>>>>>>>>>>> protostuff, protobuf, msgpack > >>>>>>>>>>>>>>>>>>>> and of course standard > >>>>>>>>>>>>>>> serialization), > >>>>>>>>>>>>>>>>>>> about > >>>>>>>>>>>>>>>>>>>> creating a simple embedded > >>>>>>>>>>>>>>>>>>>> serializer leveraging the > >>>>>>>>>>>>>>>>>>>> same > >>>>>>>>>>>>>>> techniques > >>>>>>>>>>>>>>>>> you > >>>>>>>>>>>>>>>>>>>> used (Unsafe and bytecode > >>>>>>>>>>>>>>>>>>>> generation). The idea with > >>>>>>>>>>>>>>>>>>>> embedding is avoiding to > >>>>>>>>>>>>>>>>>>>> serialize in a byte array > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>> then > >>>>>>>>>>>>>>>>>>>> moving the byte array to > >>>>>>>>>>>>>>>>>>>> off-heap memory (via Unsafe > >>>>>>>>>>>>>>>>>>>> or > >>>>>>>>>>>>>>> ByteBuffers), > >>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> serializing directly into a > >>>>>>>>>>>>>>>>>>>> "managed" off-heap buffer, > >>>>>>>>>>>>>>>>>>>> thus > >>>>>>>>>>> further > >>>>>>>>>>>>>>>>>>>> optimizing heap utilization > >>>>>>>>>>>>>>>>>>>> (less GC). > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> What do you think about it? > >>>>>>>>>>>>>>>>>>>> Does it make any sense to > >>>>>>>>>>>>>>>>>>>> you? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Ciao, R > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Sat, Sep 29, 2012 at 2:40 > >>>>>>>>>>>>>>>>>>>> PM, Noctarius > >>>>>>>>>>>>>>>>>>>> <[email protected]> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hey guys, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Raffaele found out about a > >>>>>>>>>>>>>>>>>>>>> project of mine (Lightning) > >>>>>>>>>>>>>>>>>>>>> a few > >>>>>>>>>>> weeks > >>>>>>>>>>>>>>>>>>>>> ago. Lightning is a heavy > >>>>>>>>>>>>>>>>>>>>> Unsafe and Bytecode > >>>>>>>>>>>>>>>>>>>>> generation using > >>>>>>>>>>>>>>>>>>>>> Serializer implementation. > >>>>>>>>>>>>>>>>>>>>> He told me that he was > >>>>>>>>>>>>>>>>>>>>> interested in adding > >>>>>>>>>>>>>>>>>>>>> something similar to > >>>>>>>>>>>>>>>>>>>>> DirectMemory and I would be > >>>>>>>>>>>>>>>>>>>>> glad to > >>>>>>>>>>>>>>> help > >>>>>>>>>>>>>>>>>>>>> out in this. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Another project I started a > >>>>>>>>>>>>>>>>>>>>> few days ago, since it was > >>>>>>>>>>>>>>>>>>>>> needed > >>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>> work is DirectRingCache. > >>>>>>>>>>>>>>>>>>>>> The name not really meets > >>>>>>>>>>>>>>>>>>>>> to actual implementation > >>>>>>>>>>>>>>>>>>>>> since it's not yet a ring > >>>>>>>>>>>>>>>>>>>>> buffer using cache. I > >>>>>>>>>>>>>>> used > >>>>>>>>>>>>>>>>>>>>> this for a > >>>>>>>>>>>>>>>>>>>>> pre-serialization simple > >>>>>>>>>>>>>>>>>>>>> bytestream cache with > >>>>>>>>>>>>>>>>>>>>> self-growing buffers. It > >>>>>>>>>>>>>>>>>>>>> could be nice to have > >>>>>>>>>>>>>>>>>>>>> DirectMemory > >>>>>>>>>>> having > >>>>>>>>>>>>>>>>>>>>> raw "buffers" to write to > >>>>>>>>>>>>>>>>>>>>> or to read from. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Here are the links from > >>>>>>>>>>>>>>>>>>>>> the projects: > >>>>>>>>>>>>>>>>>>>>> https://github.com/noctarius/Lightning > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >> https://github.com/noctarius/direct-ring-cache > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> It would be nice to help out since I really like > >>>>>>>>> the idea of > >>>>>>>>>>>>>>>>>>>>> DirectMemory and since > >>>>>>>>>>>>>>>>>>>>> direct-ring-cache is some > >>>>>>>>>>>>>>>>>>>>> kind of > >>>>>>>>>>>>>>> reinventing > >>>>>>>>>>>>>>>>>>>>> the wheel. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Cheers Noctarius (Chris) > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -- 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 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- 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 > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > > >
