Mailing-List: contact dev-help@directmemory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@directmemory.apache.org
Received-SPF: pass (nike.apache.org: domain of raffaele.p.guidi@gmail.com
 designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50683149.1020800@noctarius.com>
References: <5066EC3F.6040602@noctarius.com>
	<CAAnVOG1iFR54qNU1kdVZuF_RFt72vf=24n6i9bziQbnOTag82w@mail.gmail.com>
	<506716DD.3080700@noctarius.com>
	<CAAnVOG0D5D3P4N9HczKK2KtcV+TNKeYvE_yA-JN4WiB2hyw4Rw@mail.gmail.com>
	<CAPoyBqTd6Jdr4b5Nh2DENQisbPcRYvK5cMCgp9UQdRr=RmQosg@mail.gmail.com>
	<CAAnVOG2WbSB3QEk2_sWLRgufq1kUFAKoMjyiQWv6nWPN5peTGw@mail.gmail.com>
	<50672684.70802@noctarius.com>
	<CAPoyBqRtEBbb7m1iX_rnQ249ac-0=i8WMD-2G6swZu-dcw0yMQ@mail.gmail.com>
	<5067292E.3000208@noctarius.com>
	<CAPoyBqSrmhpYwOSCBN=ySDagg9tGGszR9NivYeCXDOgpFkgEqg@mail.gmail.com>
	<CAAnVOG076QC21byi9dLe2HhBeKh8ih7f0OQjzSCNmobhmko=9A@mail.gmail.com>
	<50673CCF.1050308@noctarius.com>
	<CAAnVOG11D_SbG1ZkAb6n3PJwtsz7SFgj7jn8_q0QnVXwF+NC0A@mail.gmail.com>
	<506741E9.1010706@noctarius.com>
	<CAAnVOG3dQfw6Tm3xYQrWFwV25X-RqoNXdWcAT-ffkp-HAsQQ4w@mail.gmail.com>
	<506801DD.6040609@noctarius.com>
	<CAAnVOG0uaEVwg5SLecy-rOxJn7M_RW4WJgRWcy7SLn-6TNnmmg@mail.gmail.com>
	<50683149.1020800@noctarius.com>
Date: Sun, 30 Sep 2012 13:56:20 +0200
Message-ID: 
 <CAAnVOG3BLSO6zXeA27Nvbg_WP8p8PSdjG-qyBUVcCo+nX=gcpw@mail.gmail.com>
Subject: Re: Additional Serializer and raw Buffer access
From: "Raffaele P. Guidi" <raffaele.p.guidi@gmail.com>
To: dev@directmemory.apache.org
Content-Type: multipart/alternative; boundary=e0cb4e7004472d389a04cae9fa0f

--e0cb4e7004472d389a04cae9fa0f
Content-Type: text/plain; charset=ISO-8859-1

Don't tell me... worked on github for too long :-D
Il giorno 30/set/2012 13:48, "Noctarius" <me@noctarius.com> ha scritto:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ok this is the issue url. Hope the patch is ok because it's been
> long since last used diff files :-)
>
> https://issues.apache.org/jira/browse/DIRECTMEMORY-102
>
> Am 30.09.2012 10:40, schrieb Raffaele P. Guidi:
> > OK let's keep them out then Il giorno 30/set/2012 10:26,
> > "Noctarius" <me@noctarius.com> 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" <me@noctarius.com> 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
> >>>>> <me@noctarius.com> 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" <olamy@apache.org> ha
> >>>>>> scritto:
> >>>>>>>
> >>>>>>>> 2012/9/29 Noctarius <me@noctarius.com>:
> >>>>>>>>> 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 <me@noctarius.com>:
> >>>>>>>>>>> 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" <olamy@apache.org> ha
> >>>>>>>>>>>> scritto:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 2012/9/29 Raffaele P. Guidi
> >>>>>>>>>>>>> <raffaele.p.guidi@gmail.com>:
> >>>>>>>>>>>>>> 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" <me@noctarius.com> 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"
> >>>>>>>>>>>>>>>> <olamy@apache.org> ha
> >>>>>>>>>>>>>>> scritto:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2012/9/29 Raffaele P. Guidi
> >>>>>>>>>>>>>>>>> <raffaele.p.guidi@gmail.com>:
> >>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>> <olamy@apache.org>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 2012/9/29 Raffaele P.
> >>>>>>>>>>>>>>>>>>> Guidi
> >>>>>>>>>>>>>>>>>>> <raffaele.p.guidi@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> 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
> >>>>>>>>>>>>>>>>>>>> <me@noctarius.com>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>> <me@noctarius.com>
> >>>>>>>>>>>>>>>>> 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/
>
> iQIcBAEBAgAGBQJQaDFIAAoJEH/g+YBfahrqvAoP/jGZfWAyHitz48sTKvmk+f2Y
> NvkWELdPUIyhvyY0bpcV/dDv8ih94bkmSU0Tk1N22SJApetUM6PJaa+1QhVHRF7W
> 3x+fDfK9OWiAI/eBpEKjYlUrDzHh72eHmpU1tf9o0dxK+ADIJsvs4cUxtNuoCWx7
> rg6rV67f+r1ba1zfylMC4oG1T9EFLedbmWZQ6xY3TwG/Iplqz5tFg8OghK097PTP
> BYky2keKl/Tfj3HpvpqaORomJsqJLwirDm1YD7ivYN4UL/7QiEUzOtzHwDq+b1jJ
> CgHZMjQlJPDUGxb7zl+xPfi7afOxRBXuZDSb5NJfKRWUM66KISBvhzGTiRg/uMME
> uTqFufFSA1MY/Eg/ZODOmFW+jqth0jgGIwLN1ptcZH3H3IoafpXBhb6eC1lDvSI2
> zkgsvY0boSsyQggzbXuO/z6qCgayl9/XSsaxacMnvLuzIr/I+eJFVHWeYrpcV9Lz
> PE0i89fVih/ZaGijkqpzOd8O3u7v7n1o47Xd8tChNDqPy/gNRUxVnnUmJOtdUpyg
> TC3jNDkkT4WqhgbdiNWO1ypADa5VrSvc2I/O/AVWF6vbEa5uvxov0nCdyqzLM0oB
> UShPtggDH9exKU4XXcEjLfCHlQCtFN315sG9X8TBNxBuptfDrbGwadN7THpjXfj4
> xcDZpJbJQsL96ZsL9E1f
> =jT/+
> -----END PGP SIGNATURE-----
>

--e0cb4e7004472d389a04cae9fa0f--