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 > >>>> > >>> > >> > > > >
