-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Morning,
is there any way to preserve the commit history? I don't think so. Cheers Chris 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 >>>>>> >>>>> >>>> >>> >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQZ/ZZAAoJEH/g+YBfahrqbIUQALEwBddCj1OY7z2QYgUDze6u t2RfhWdWpArExVG4vof46xwJ6RmF5T6muIjl3MoR8B6dG46QeBxv3bPq0RmUkcAF U8USSMnC9w6Qr6DCjCwjqLb7dnUBgNGqLIMdIIePX7+UxnOOsQ9l4Ext0Vsz5xn3 2qkmy7nxiuBkox9OJlXlB8Nt//3LgHRi3iIuBpZ6S4GEwILIQ/UT0WuGKFx6+Sa7 bOwtSnViERwYNUiFth8O3SS4KmCsEHwWijV6vd+/jxVGhFqMSzxhj5++KzhCe+GZ /WavR3rrvmZot9Mmpc4wDWj+6l6PXQrIXqxZDy9SrV7619r0Mh/SvbAKasP+/uMb XLjQ/eZoAXRJ34G2l9l3q33lqwv7GK0+zcmgbgX6qun1eKUMuTR/08qfxu1UZO/k MMAEZKfT50sNiEDHFKqyGLk8hgTh4nvoCPwxNZBWbezgIFg+8NdigdAlgIxWb+59 HwTaFtGmbZYkje0dx6WkoNXgLUsLLGOAq+rSbn4Pz3594hb7leJOIgGKUXA1/Eak XoXFaXR/eg9ICuzrgN17Apz7GqN4HT3HxmGk6h+J6jkLTFOfyK5J6WQpP0hEXU5O 7dH6q0Zc/Af1J8eT2IGUrbbbwRWwXxIBUEQocon4VoDa219gmev/fxrRlL1xuB9f 7LS2c0gONRWWdl7M5n8+ =/dDf -----END PGP SIGNATURE-----
