In Gson, we agonized over this issue periodically.
In the end, I think our current approach works. Just support fields (public
or private), and ignore methods. The developers should use custom type
adapters for anything more complicated.
Inder
On Fri, Apr 10, 2015 at 12:33 PM, Romain Manni-Bucau <
rmannibucau_at_tomitribe.com> wrote:
> Well issue supporting private fields by default is you dont expose correct
> payload (API for REST endpoint!!) if you need any internal variable which
> is super risky compared to have to activate field visibility manually.
>
> That said I am happy while it is customizable.
> Le 10 avr. 2015 20:38, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a écrit :
>
>>
>>
>> 2015-04-10 20:11 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>
>>> Interesting point of view. I was thinking mainly about deser scenario
>>> and no mixin.
>>>
>>> I still see public fields more like a not so good design decision
>>> (instead of public contract).
>>>
>>
>> Depends, public final fields look good to me (only if final). Esp. when
>> it is supposed to exclusively hold "public" data.
>> But I guess it is more of a religion if you are alergic to get/set or not
>> - as you can guess I am :)
>>
>>
>>>
>>> I think there are two regular cases:
>>>
>>> 1. class with all fields private with get/set methods
>>>
>>> 2. class with just non public fields
>>>
>>> Other not so good cases (by design) :)
>>>
>>> - class with all fields public (no get/set)
>>>
>>> - class with mix of fields and get/set methods.
>>>
>>> Anyway, I still think it is better to support all these cases. If user
>>> doesn't want some property to be serialized into json, he could put
>>> annotation or transient keyword on the given field or set/get method.
>>>
>>>
>> Yeah sure but it could be the other way too, only public + annotate what
>> else you want to include or configure your instance of Jsonb to do so.
>> Anyway, if there is a option to configure visibility in Jsonb (without
>> annotations) I am fine with it.
>>
>> Eugen
>>
>>
>>> What do others think about support of private fields by default?
>>>
>>
>>> MartinV
>>>
>>>
>>> On Fri, Apr 10, 2015 at 7:11 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>>> wrote:
>>>
>>>> Just some insights about mixing by default public and private...
>>>>
>>>> 2015-04-08 20:31 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>>>
>>>>> I vote for the following (default mapping):
>>>>>
>>>>> - support private fields (private fields are good habit in Java)
>>>>>
>>>>
>>>> Doing ser/de by using private fields when at the same time one uses
>>>> public contract can be source of problems.
>>>>
>>>> As a user
>>>> - I want to ser/de all the private fields when I am doing some RPC
>>>> because on the other side I will use this technical low level
>>>> representation to provide the same contract other the private data (in this
>>>> situation I just don't want the lib to look at methods, but take all the
>>>> private fields except transient/static).
>>>>
>>>> - I want to ser/de using public methods and fields to expose a kind of
>>>> API/public data. In this situation I don't want the lib to pick my private
>>>> fields because they are the way I internally represent stuff, the consumer
>>>> doesn't have to know about that.
>>>>
>>>> That's also the logic I followed when making Genson. I think exposing
>>>> both by default is wrong...(but one can still use the annotations from a
>>>> field and apply them to a method, just not ser/de protected/private stuff
>>>> by default)
>>>>
>>>>
>>>>
>>>>> - support get/set
>>>>>
>>>>> If there is get/set, use it.
>>>>> If there is just field, use it.
>>>>> If there is just get/set and no field, use get/set.
>>>>>
>>>>> Other options should be configurable.
>>>>>
>>>>> MartinV
>>>>>
>>>>> On Wed, Apr 8, 2015 at 11:25 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-04-08 10:17 GMT+02:00 Hendrik Dev <hendrikdev22_at_gmail.com>:
>>>>>>
>>>>>>> (sorry, wrong list)
>>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Hendrik Dev <hendrikdev22_at_gmail.com>
>>>>>>> Date: Wed, Apr 8, 2015 at 10:16 AM
>>>>>>> Subject: Re: [jsonb-spec users] Re: [jsr367-experts] Re: Re: Re:
>>>>>>> [30-GenericTypeSupport] Proposal
>>>>>>> To: users_at_jsonb-spec.java.net
>>>>>>>
>>>>>>>
>>>>>>> I would say: Support all variants (fields and/or (getters/setters))
>>>>>>> including private fields and by default use only getter/setters (and
>>>>>>> no fields). Thats what the most users would expect AFAIK.
>>>>>>>
>>>>>>
>>>>>> In genson I include public fields by default, it sounds natural to me
>>>>>> as the public methods and fields define the "exposed" contract about the
>>>>>> data. Then users can customize it as they want.
>>>>>>
>>>>>>
>>>>>>> Dont know if just getters or just setters is really useful, IMHO it
>>>>>>> complicates the thing without adding real value (can be done with
>>>>>>> @Ignore if really necessary)
>>>>>>>
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> We do this in Johnzon via AccessMode
>>>>>>> (
>>>>>>> https://github.com/apache/incubator-johnzon/blob/master/johnzon-mapper/src/main/java/org/apache/johnzon/mapper/access/AccessMode.java
>>>>>>> )
>>>>>>>
>>>>>>> Thanks
>>>>>>> Hendrik
>>>>>>>
>>>>>>> On Wed, Apr 8, 2015 at 9:33 AM, Oleg Tsal-Tsalko <
>>>>>>> oleg.tsalko_at_gmail.com> wrote:
>>>>>>> > Hi guys,
>>>>>>> >
>>>>>>> > My vote (if it counts) is to definitely support by default all
>>>>>>> variants
>>>>>>> > (e.g. fields/getters/setters) in all combinations (e.g.
>>>>>>> getters+setters or
>>>>>>> > just getters or just setters even if it silly usage from user
>>>>>>> perspective) +
>>>>>>> > with private access.
>>>>>>> > The only thing we need to decide on relative priorities to resolve
>>>>>>> ties if
>>>>>>> > any.
>>>>>>> >
>>>>>>> > Thank you,
>>>>>>> > Oleg
>>>>>>> >
>>>>>>> >
>>>>>>> > 2015-04-07 22:16 GMT+03:00 Romain MB <rmannibucau_at_tomitribe.com>:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Le 7 avr. 2015 21:07, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a
>>>>>>> écrit :
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > 2015-04-07 20:48 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com
>>>>>>> >:
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> Le 7 avr. 2015 20:27, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a
>>>>>>> écrit :
>>>>>>> >> >> >
>>>>>>> >> >> >
>>>>>>> >> >> >
>>>>>>> >> >> > 2015-04-07 20:05 GMT+02:00 Romain MB <
>>>>>>> rmannibucau_at_tomitribe.com>:
>>>>>>> >> >> >>
>>>>>>> >> >> >> Hi
>>>>>>> >> >> >>
>>>>>>> >> >> >> This topic is very interesting but I think we should just
>>>>>>> align by
>>>>>>> >> >> >> default on javabeans and allow a configuration (+api) for
>>>>>>> other usages which
>>>>>>> >> >> >> are widely spread over applications.
>>>>>>> >> >> >>
>>>>>>> >> >> >> So I propose:
>>>>>>> >> >> >>
>>>>>>> >> >> >> - default: getter/setter only, no field check at all,
>>>>>>> >> >> >
>>>>>>> >> >> >
>>>>>>> >> >> > I think it is more friendly to have public methods and
>>>>>>> fields (for
>>>>>>> >> >> > example if one has a immutable pojo with all fields public).
>>>>>>> >> >> >
>>>>>>> >> >>
>>>>>>> >> >> Fair enough
>>>>>>> >> >>
>>>>>>> >> >> >>
>>>>>>> >> >> >> support of addX for collections and maybe getter in write
>>>>>>> mode as in
>>>>>>> >> >> >> jaxb.
>>>>>>> >> >> >
>>>>>>> >> >> > I am hesitating for addX not sure I like it...
>>>>>>> >> >> > What is getter in write mode?
>>>>>>> >> >> >
>>>>>>> >> >>
>>>>>>> >> >> getMyCollection().add(xx) instead of just using
>>>>>>> setMyCollection(col)
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > Ok I understand better what you mean. I can see only 2 use
>>>>>>> cases for
>>>>>>> >> > this: when adding stuff to the list the pojo is doing something
>>>>>>> (increment a
>>>>>>> >> > counter for example) or updating an existing instance (kind of
>>>>>>> merge).
>>>>>>> >>
>>>>>>> >> Well jaxb does it cause setColl makes the API not that natural I
>>>>>>> think.
>>>>>>> >>
>>>>>>> >> > I don't think we provide any merge solution now so point 2 is
>>>>>>> excluded
>>>>>>> >> > and 1 is still valid even if I don't like it :)
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >> +0, being aligned on other specs would be nice as well. JPA
>>>>>>> started
>>>>>>> >> without merges then added it to make it smooth for users. When we
>>>>>>> dont know
>>>>>>> >> or there is a conflict it is easy to fail - like jaxb.
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> > Eugen
>>>>>>> >> >>
>>>>>>> >> >> >>
>>>>>>> >> >> >> I like it cause it really exposes an API and not internals.
>>>>>>> >> >> >> - a shortcut in config api to use fields (either only or in
>>>>>>> >> >> >> cumulative mode) - this is too common to not be handled and
>>>>>>> the default in
>>>>>>> >> >> >> most ee API (JPA for instance)
>>>>>>> >> >> >> - add in API an abstraction for it for advanced mode and
>>>>>>> evolutions
>>>>>>> >> >> >> (Accessor, and AccessorFinder - I am not happy of the
>>>>>>> naming but was to
>>>>>>> >> >> >> share the idea). It would allow to add processor on the
>>>>>>> accessors to filter
>>>>>>> >> >> >> or remap them pretty easily. It makes trivial remapping,
>>>>>>> version and
>>>>>>> >> >> >> blacklist handling for instance.
>>>>>>> >> >> >>
>>>>>>> >> >> >> Le 7 avr. 2015 19:57, "Martin Vojtek" <voytoo_at_gmail.com> a
>>>>>>> écrit :
>>>>>>> >> >> >>>
>>>>>>> >> >> >>> It would be great to hear opinions from others on this
>>>>>>> topic.
>>>>>>> >> >> >>>
>>>>>>> >> >> >>> Current JSON-B proposal is to by default ser/deser only
>>>>>>> fields
>>>>>>> >> >> >>> where field is present. Specifically, if there is field
>>>>>>> and set/get method,
>>>>>>> >> >> >>> set/get method is used. If there is not set/get method,
>>>>>>> field is used. If
>>>>>>> >> >> >>> there is no field, but get/set method, it is not used
>>>>>>> (JSON-B will not
>>>>>>> >> >> >>> consider this property). This behavior should be
>>>>>>> customizable. Maybe it is
>>>>>>> >> >> >>> too restrictive and if there is getter and no field,
>>>>>>> getter should be used.
>>>>>>> >> >> >>> What if there are methods not intended to be getters? What
>>>>>>> if there is
>>>>>>> >> >> >>> method isValue and getValue?
>>>>>>> >> >> >>>
>>>>>>> >> >> >>> For properties that are being renamed ... I can imagine
>>>>>>> use of
>>>>>>> >> >> >>> annotations.
>>>>>>> >> >> >>>
>>>>>>> >> >> >>> MartinV
>>>>>>> >> >> >>>
>>>>>>> >> >> >>> On Tue, Apr 7, 2015 at 4:27 PM, Eugen Cepoi <
>>>>>>> cepoi.eugen_at_gmail.com>
>>>>>>> >> >> >>> wrote:
>>>>>>> >> >> >>>>
>>>>>>> >> >> >>>> Oh, yes, in fact this is something I did on purpose for a
>>>>>>> couple
>>>>>>> >> >> >>>> of reasons. One of them is to allow people to ser types
>>>>>>> based on some
>>>>>>> >> >> >>>> "parent type". For example if a class implements several
>>>>>>> interfaces and we
>>>>>>> >> >> >>>> want to serialize using only one "aspect" of the instance.
>>>>>>> >> >> >>>> The other reasons are more opinionated :)
>>>>>>> >> >> >>>>
>>>>>>> >> >> >>>> So in JSONB how do you see things, would we ser only
>>>>>>> properties
>>>>>>> >> >> >>>> that have a field+get+set? I would prefer not or at least
>>>>>>> provide a config
>>>>>>> >> >> >>>> for it.
>>>>>>> >> >> >>>>
>>>>>>> >> >> >>>> However something that is a bit similar, from what I've
>>>>>>> seen,
>>>>>>> >> >> >>>> merging annotations from field/get/set is the good way to
>>>>>>> go. Initially I
>>>>>>> >> >> >>>> thought it would be better to decouple ser from deser
>>>>>>> aspect. But in the end
>>>>>>> >> >> >>>> I found that from an usage point of view, people expect
>>>>>>> that annotations
>>>>>>> >> >> >>>> that have been put on the field are being used also for
>>>>>>> get and set. The
>>>>>>> >> >> >>>> issue with this is how would one handle properties that
>>>>>>> are being renamed? I
>>>>>>> >> >> >>>> am quite interested in others opinion on this as I
>>>>>>> couldn't make my mind yet
>>>>>>> >> >> >>>> :)
>>>>>>> >> >> >>>>
>>>>>>> >> >> >>>> Thanks!
>>>>>>> >> >> >>>> Eugen
>>>>>>> >> >> >>>>
>>>>>>> >> >> >>>> 2015-04-07 16:00 GMT+02:00 Martin Vojtek <
>>>>>>> voytoo_at_gmail.com>:
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> The example I was thinking about is following:
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> interface FunctionalInterface<T> {
>>>>>>> >> >> >>>>> public T getValue();
>>>>>>> >> >> >>>>> }
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> Genson:
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> public void test() {
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> FunctionalInterface<String> myFunction = () ->
>>>>>>> {return
>>>>>>> >> >> >>>>> "value1";};
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> assertEquals("{\"value\":\"value1\"}",
>>>>>>> >> >> >>>>> genson.serialize(myFunction));
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> }
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> Proposed JSON-B:
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> FunctionalInterface<String> myFunction = () -> {return
>>>>>>> >> >> >>>>> "value1";};
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> assertEquals("{}", jsonb.toJson(myFunction));
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> The difference is in handling getters when there is no
>>>>>>> field.
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> MartinV
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>> On Mon, Apr 6, 2015 at 11:22 PM, Eugen Cepoi
>>>>>>> >> >> >>>>> <cepoi.eugen_at_gmail.com> wrote:
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>> 2015-04-06 22:47 GMT+02:00 Martin Vojtek <
>>>>>>> voytoo_at_gmail.com>:
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> Hi,
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> response inlined.
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> Thanks,
>>>>>>> >> >> >>>>>>> Martin
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> On Sun, Apr 5, 2015 at 5:57 PM, Oleg Tsal-Tsalko
>>>>>>> >> >> >>>>>>> <oleg.tsalko_at_gmail.com> wrote:
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> Hi guys,
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> Feedback on generic mapping serialization examples:
>>>>>>> >> >> >>>>>>>> 1) Why there are no examples of actual usage of
>>>>>>> proposed
>>>>>>> >> >> >>>>>>>> Jsonb#toJson(Object, Type) method?
>>>>>>> >> >> >>>>>>>> I assume these examples should justify usage of this
>>>>>>> advanced
>>>>>>> >> >> >>>>>>>> method in those special/tricky cases where
>>>>>>> Jsonb#toJson(Object) method is
>>>>>>> >> >> >>>>>>>> not enough.
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> Will add example:
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> List<java.util.Optional<String>> expected =
>>>>>>> >> >> >>>>>>> Arrays.asList(Optional.empty(),
>>>>>>> Optional.ofNullable("first"),
>>>>>>> >> >> >>>>>>> Optional.of("second"));
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> String json = toJson(expected,
>>>>>>> >> >> >>>>>>>
>>>>>>> DefaultMappingGenerics.class.getField("listOfOptionalStringField").getGenericType());
>>>>>>> >> >> >>>>>>> assertEquals("[null,\"first\",\"second\"]",json);
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> 2) Probably it was missed by me but are we going to
>>>>>>> support
>>>>>>> >> >> >>>>>>>> serialization of anonymous interfaces/classes
>>>>>>> implementations at all?
>>>>>>> >> >> >>>>>>>> As an example:
>>>>>>> >> >> >>>>>>>> myFunction = new FunctionalInterface<String>() {
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>> private String value = "initValue";
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>> @Override public String getValue() {
>>>>>>> >> >> >>>>>>>>>>
>>>>>>> >> >> >>>>>>>>>> return value;
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>> }
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>> public void setValue(String value) {
>>>>>>> >> >> >>>>>>>>>>
>>>>>>> >> >> >>>>>>>>>> this.value = value;
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>> }
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> };
>>>>>>> >> >> >>>>>>>> assertEquals("{\"value\":\"initValue\"}",
>>>>>>> >> >> >>>>>>>> jsonb.toJson(myFunction));
>>>>>>> >> >> >>>>>>>> It doesn't look like valid scenarios to support.
>>>>>>> >> >> >>>>>>>> AFAIK, Gson lib doesn't support this...
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> Don't see reason why it is not valid scenario.
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> Genson supports it (with different result in some
>>>>>>> cases as
>>>>>>> >> >> >>>>>>> proposed JSON-B) :)
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>> Heh looks like you had an in depth look at it :) In what
>>>>>>> >> >> >>>>>> situation did it produce different or undexpected
>>>>>>> results?
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>> I added it because the effort to support it was not so
>>>>>>> important
>>>>>>> >> >> >>>>>> and this can be of some use. But this looks like a rare
>>>>>>> use case so I am not
>>>>>>> >> >> >>>>>> feeling strongly for or against it. I don't feel so
>>>>>>> concerned by the
>>>>>>> >> >> >>>>>> examples as IMO they are just examples and its OK if
>>>>>>> they don't cover all
>>>>>>> >> >> >>>>>> the API (after all it is not the spec).
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>> About supporting deser missing properties I 100% agree
>>>>>>> with the
>>>>>>> >> >> >>>>>> remark but think it should be expressed as a config
>>>>>>> option that would make
>>>>>>> >> >> >>>>>> things clear that impl. have to support this feature
>>>>>>> (and don't really care
>>>>>>> >> >> >>>>>> about the example).
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>> I wonder if providing those examples doesn't make
>>>>>>> things more
>>>>>>> >> >> >>>>>> confusing about what is the contract that impls should
>>>>>>> respect.
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>> Eugen
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> It would be helpful to hear some opinions from others
>>>>>>> on this
>>>>>>> >> >> >>>>>>> topic.
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> 3) Expected result in bounded example doesn't look
>>>>>>> right:
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>>
>>>>>>> assertEquals("{\"boundedSet\":[3],\"superList\":[{\"radius\":2.5}]}",
>>>>>>> >> >> >>>>>>>>> jsonb.toJson(boundedGenericClass));
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> I believe it should be:
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>>>
>>>>>>> {"boundedSet":[3],"superList":[{"area":0.0,"radius":2.5}]}
>>>>>>> >> >> >>>>>>>>>
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>> Will fix asap.
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> Have a great Easter!
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>> Thank you,
>>>>>>> >> >> >>>>>>>> Oleg
>>>>>>> >> >> >>>>>>>>
>>>>>>> >> >> >>>>>>>
>>>>>>> >> >> >>>>>>
>>>>>>> >> >> >>>>>
>>>>>>> >> >> >>>>
>>>>>>> >> >> >>>
>>>>>>> >> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hendrik Saly (salyh, hendrikdev22)
>>>>>>> @hendrikdev22
>>>>>>> PGP: 0x22D7F6EC
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hendrik Saly (salyh, hendrikdev22)
>>>>>>> @hendrikdev22
>>>>>>> PGP: 0x22D7F6EC
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>