Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKF+bsqPKH-FJnwa0qLO0m4_Q3Ar98a7KbcV+icCEvSxf-Wozg@mail.gmail.com>
References: <95C56966-F848-47A0-B587-9F0E9AAE06F9@me.com> <CAKF+bsraE6oYPfsrN5zjM7ySR5Uwq1c6gnvk6sjOp6hbpuX3pg@mail.gmail.com>
 <943F83FE-20A4-42C7-B218-9307986DB43B@me.com> <60F6BF2D-DF79-4C73-BB8B-B3396FA092FC@me.com>
 <592F37A1.9020500@gmail.com> <9FA3393F-16B3-4E1F-A692-749B42F180B6@me.com>
 <CAKF+bsppAHNA6Pv4cYA0wnUdzhDTOvYSH40SUyYCx=Jq4eWtWA@mail.gmail.com>
 <DB94ACE2-3887-4821-9759-8AABEDC21AD0@me.com> <D3C2E898-B3C5-4D32-9654-5DBDC8F62CBD@me.com>
 <CAH6wpnoHbEJuTzoTkEecmvq4iLrsGYoW8QN+tm_YPjLPYRFx+A@mail.gmail.com>
 <2c47d851-da37-1277-2699-0451df93fbe6@gmail.com> <CAH6wpnq752tPzX+FaHwDpwySVszvmKcG9UhMPcq9vr7oSdyy6Q@mail.gmail.com>
 <36bf204a-81fb-67c2-b1a5-9827f4c49822@gmail.com> <CAH6wpnrkhdMUgXVW6A1O_9JwdbW=eV4=b7YM+xz4hvaMv6SVOg@mail.gmail.com>
 <6C55B2F8-9655-4F95-AE99-C8AFD0F41426@me.com> <2248dc18-1ab1-f1fb-4581-0d7c98eee37b@gmail.com>
 <1EF12AC5-DDFD-4B20-9D43-1700CE5BBAED@me.com> <aec4a271-58d0-daaa-e337-b9af21b332b1@gmail.com>
 <57F5408B-A8C5-40E9-8D08-33502C452512@me.com> <0224aa44-4bf0-d936-d96d-8ac9b06ecaec@gmail.com>
 <186A097C-B1B5-493C-86E7-CE5CB18A411F@me.com> <CAKF+bso3WaYGsDz+AxZD2D0ViBLLT6ymvYZo_iFSEyAuR3h5Xg@mail.gmail.com>
 <98E5DBFD-98F9-4D58-970B-87AFCFD7FAD9@gmail.com> <530316A6-7927-465E-A1D5-C8B1DC5B594D@me.com>
 <CAKF+bsqPKH-FJnwa0qLO0m4_Q3Ar98a7KbcV+icCEvSxf-Wozg@mail.gmail.com>
From: Martyn Taylor <mtaylor@redhat.com>
Date: Fri, 2 Jun 2017 10:26:51 +0100
Message-ID: <CAH6wpnpwrz95qRuLkOeX200f9m09jUkXLeHPFUU+wx9F6PcnKA@mail.gmail.com>
Subject: Re: [DISCUSS] Custom Object Serialisation Support
To: dev@activemq.apache.org
Content-Type: multipart/alternative; boundary="001a113ec1e4e87d940550f6c07d"
archived-at: Fri, 02 Jun 2017 09:27:55 -0000

--001a113ec1e4e87d940550f6c07d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

So, I could originally see a requirement for controlling the
(de)serialization process for performance or security reasons, whilst also
controlling data format.  I still think having something light weight that
gives users control over this (outside of overriding the java serialization
methods) may be useful.  It would only take a couple of lines of code in
the client to do it.

But, if this thread is really only about integrating multiple technologies,
by controlling bytes that are sent over the wire then I have to agree with
Tim, in that Camel does seem to be a good fit for this problem.  Michael, I
can see your point re: the success of the Kafka model, if you feel that
this is largely down to the API and the abstraction of the serialization
process, how about just wrapping a Camel context?

On Fri, Jun 2, 2017 at 3:28 AM, Clebert Suconic <clebert.suconic@gmail.com>
wrote:

> I have a mixed feeling about this.
>
> At the same time this would fix it for both options. As it wouldn't be pa=
rt
> of the project so other people would have to find your library.
>
>
>
> However this common tooling is an issue in other cases as well.  Like I
> know some users need a pooled connection factory for both core and qpid
> JMS.
>
>
>
> So if we could create a JMS-tools package either in Artemis or somewhere
> else.  We could have this as part of the tooling.
>
>
>
> But let me sleep over anyways.  And perhaps someone will have a better id=
ea
> as I sleep.
>
>
> On Thu, Jun 1, 2017 at 6:51 PM Michael Andr=C3=A9 Pearce <
> michael.andre.pearce@me.com> wrote:
>
> > I have been looking at an alternative approach (i think its a little le=
ss
> > optimal), but in thoughts it might be more acceptable for those not
> wishing
> > this into the core jms client.
> > It means the custom object serialisation is a optional add-on rather th=
an
> > coded into the core jms client, similar idea to the way spring wraps
> > connection factories for caching connection, and others.
> >
> >
> > https://github.com/michaelandrepearce/activemq-artemis/tree/
> SerdesExtension/artemis-jms-client-extensions
> > <
> > https://github.com/michaelandrepearce/activemq-artemis/tree/
> SerdesExtension/artemis-jms-client-extensions
> > >
> >
> > It essentially is wrapping at the JMS api level, so actually would/shou=
ld
> > work for any JMS Client not just artemis, e.g. could wrap QPID client.
> >
> > Thoughts on this approach rather than native integration to the clients=
?
> >
> >
> >
> > > On 1 Jun 2017, at 21:54, Matt Pavlovich <mattrpav@gmail.com> wrote:
> > >
> > > I understand the usefulness of adding this to the Client Connection
> > Factory vs kicking all the way up to an integration stack (like Camel).
> In
> > my eyes, its about solving for cross-platform object serialization usin=
g
> > byte payloads instead of the problems associated with non-portable/cros=
s
> > platform ObjectMessage and MapMessage JMS message types. Tibco-RV was
> > really good for that as well.
> > >
> > > IMHO=E2=80=94 plugging in protobuf, Avro, or other binary-serializati=
on
> > flavor-of-the-month at the connection factory level has real value.
> > >
> > >> On Jun 1, 2017, at 2:23 PM, Clebert Suconic <
> clebert.suconic@gmail.com>
> > wrote:
> > >>
> > >> I honestly don't see an issue on making the write and readObject a
> > >> pluggable operation. It's a simple change on the API at
> > >> ActiveMQConnectionFactory.
> > >>
> > >> On Thu, Jun 1, 2017 at 1:09 PM, Michael Andr=C3=A9 Pearce
> > >> <michael.andre.pearce@me.com> wrote:
> > >>> This is why the proposal is for a pluggable interface to declared t=
o
> > convert from Object to byte[] and back not saying one moment Artemis ow=
ns
> > or has all the implementations.
> > >>>
> > >>> Anyhow your points are taken on board, we def need to agree on a we=
ll
> > defined and clean api, to avoid exactly that situation.
> > >>>
> > >>> Sent from my iPhone
> > >>>
> > >>>> On 1 Jun 2017, at 17:59, Timothy Bish <tabish121@gmail.com> wrote:
> > >>>>
> > >>>>> On 06/01/2017 12:49 PM, Michael Andr=C3=A9 Pearce wrote:
> > >>>>> Not at all that's the point
> > >>>>>
> > >>>>> Application code uses JMS Api. The serdes are just defined/declar=
ed
> > into the connection factory typically the only part of the app exposed =
to
> > any particulars about the broker implementation detail.
> > >>>>>
> > >>>>> Yes we can do converter.convert(object) in code, this is just
> manual
> > code in the app space.
> > >>>>>
> > >>>>> but like with kafka and I have to stress it's successfulness is
> that
> > that converter is in it's api of the product. Which means a lot of
> > companies reuse a few single implementations and a good eco system occu=
rs
> > like with schema registry (Eg we use confluents serdes we don't code ou=
t
> > own)
> > >>>>
> > >>>> Which is exactly what camel can solve and without starting down th=
e
> > slippery slop of packing the same data format conversions Camel can
> already
> > handle into the Artemis code base as will happen as each user wants the=
ir
> > own preferred data format.
> > >>>>
> > >>>> Similar things were tried in the ActiveMQ 5.x code and abandoned
> over
> > time so I'd like to avoid that if possible.
> > >>>>
> > >>>> Anyway, I've raised my objection.
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Sent from my iPhone
> > >>>>>
> > >>>>>>> On 1 Jun 2017, at 17:39, Timothy Bish <tabish121@gmail.com>
> wrote:
> > >>>>>>>
> > >>>>>>> On 06/01/2017 12:19 PM, Michael Andr=C3=A9 Pearce wrote:
> > >>>>>>> Agreed it does as an EAI pattern or flow, But I have to
> > code/define into Camel's dsl, it does JMS as much as our custom app cod=
e
> > would it consumes the JMS api.
> > >>>>>> So you still need to code / define the serialization then and
> > include that in you application which means the difference between some
> > connection.setSerializationThing() vs
> > producer.send(Converter.convert(payload)); so I don't see how that is a
> > real value add to the JMS client.
> > >>>>>>
> > >>>>>>> What we propose here is just providing a clean way to define th=
e
> > JMS ObjectMessage internal serialisation. If Java serialisation isn't
> your
> > cup of tea. (Which for many reasons isn't for us, and I'm sure it's
> similar
> > for others)
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>>> On 1 Jun 2017, at 16:58, Timothy Bish <tabish121@gmail.com>
> > wrote:
> > >>>>>>>>>
> > >>>>>>>>> On 06/01/2017 11:50 AM, Michael Andr=C3=A9 Pearce wrote:
> > >>>>>>>>> Really this is much more about how an ObjectMessage serialize=
s
> > the Object. As we have C++ clients etc that obviously won't be able to
> > understand Java serialized object.
> > >>>>>>>>>
> > >>>>>>>>> We use Avro and a schema repo for our dto transfer over the
> > wire, it's been a real performance boost , and removed some core data
> > issues, and really like to use it over the JMS land.
> > >>>>>>>>>
> > >>>>>>>>> One can argue that you could manually code this that you
> > serialize the data manually first and then just manually send a
> > BytesMessage.
> > >>>>>>>>>
> > >>>>>>>>> But I think taking some inspiration from other places where a
> > serdes pattern is done has really helped (Kafka), from a corporation us=
er
> > approach wiring some prebuilt serdes into a factory is very easy, havin=
g
> > duplicated code in many many apps leaves for issues, and implementation
> > divergence.
> > >>>>>>>>>
> > >>>>>>>>> The one downside of Kafka is it's lack of spec api, this is o=
ne
> > big sell of artemis as it's JMS compliant. Coding against JMS api for
> Java
> > estate is a huge win, this is suggesting taking some of the good bits :=
).
> > >>>>>>>>>
> > >>>>>>>>> Does camel expose this as some sort of JMS API wrapper? I
> > thought it was much more an EAI solution.
> > >>>>>>>>>
> > >>>>>>>>> Cheers
> > >>>>>>>>> Mike
> > >>>>>>>> Camel does JMS transport: http://camel.apache.org/sjms.html
> > >>>>>>>> Camel does AVRO: http://camel.apache.org/avro.html
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> Sent from my iPhone
> > >>>>>>>>>
> > >>>>>>>>>>>> On 1 Jun 2017, at 15:18, Martyn Taylor <mtaylor@redhat.com=
>
> > wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish <
> > tabish121@gmail.com> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish <
> > tabish121@gmail.com> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
> > >>>>>>>>>>>>>> I get the use case for using JSON/XML, particularly for
> > cross language
> > >>>>>>>>>>>>>> communication.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> One way users get around this problem right now is just =
to
> > serialize
> > >>>>>>>>>>>>>> to/from XML/JSON at the client application level and jus=
t
> > use JMS
> > >>>>>>>>>>>>>> TextMessages to send the data. I guess the idea here to
> > remove that
> > >>>>>>>>>>>>>> complexity from the client application and into the clie=
nt
> > via these
> > >>>>>>>>>>>>>> pluggable serializer objects?  Removing the serizliation
> > logic out of
> > >>>>>>>>>>>>>> code
> > >>>>>>>>>>>>>> and into configuration.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Providing I've understood this properly, it seems like a
> > good idea to
> > >>>>>>>>>>>>>> me.
> > >>>>>>>>>>>>>> so +1.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> This problem has already been solved via frameworks like
> > Apache Camel,
> > >>>>>>>>>>>>> putting such complexity into the JMS client is solving a
> > problem that's
> > >>>>>>>>>>>>> already been solved and in much more flexible and
> > configurable ways.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks Tim.  I am not a Camel expert in any shape or form,
> > how much
> > >>>>>>>>>>>> additional complexity/configuration would be required to d=
o
> > something
> > >>>>>>>>>>>> similar with Camel?  My understanding of the proposal here
> is
> > really just
> > >>>>>>>>>>>> to give control back to the user in terms of how their
> > objects are
> > >>>>>>>>>>>> serialized.  I'd expect this to be pretty light weight, ju=
st
> > allow a user
> > >>>>>>>>>>>> to configure a class to do the serialization.
> > >>>>>>>>>>>>
> > >>>>>>>>>>> Camel offers conversions for a number of data formats
> > >>>>>>>>>> Sure.   Though, one of the drivers (mentioned in this thread=
)
> > for having
> > >>>>>>>>>> control over the de/serialization process was for performanc=
e.
> > Converting
> > >>>>>>>>>> to another format is going to obviously make this much worse=
.
> > >>>>>>>>>>
> > >>>>>>>>>>> as well as routing amongst numerous protocols, have a look =
at
> > the
> > >>>>>>>>>>> supported data formats page:
> > http://camel.apache.org/data-format.html and
> > >>>>>>>>>>> the transports http://camel.apache.org/transport.html
> > >>>>>>>>>>> This doesn't seem to be doing much more for the user than
> > moving the work
> > >>>>>>>>>>> they need to do around,
> > >>>>>>>>>> Well, it abstracts the de/serialization process out of
> > application code.
> > >>>>>>>>>>
> > >>>>>>>>>>> they still have to implement or configure the mechanics of
> the
> > >>>>>>>>>>> transformation of the data format to the appropriate JMS
> > message type and
> > >>>>>>>>>>> back again.  Even if you bake in something to the client to
> > handle some
> > >>>>>>>>>>> common formats you will quickly find that it doesn't meet
> > everyone's needs
> > >>>>>>>>>>> and you'll end up implementing a poor mans Camel inside a J=
MS
> > API
> > >>>>>>>>>>> restricted client which seems less than ideal.
> > >>>>>>>>>> I agree reinventing the wheel (badly) is not a good idea.  S=
o,
> > if Camel is
> > >>>>>>>>>> able to provide us with a solution to the problem, that
> > addresses the
> > >>>>>>>>>> issues outlined here.  Then, we should certainly look into i=
t.
> > >>>>>>>>>>
> > >>>>>>>>>> Cheers.
> > >>>>>>>>>>
> > >>>>>>>>>>>> On Thu, Jun 1, 2017 at 7:44 AM, Michael Andr=C3=A9 Pearce =
<
> > >>>>>>>>>>>>>> michael.andre.pearce@me.com> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I think i might be getting the problem, use case you wan=
t
> > to go for,
> > >>>>>>>>>>>>>> which
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> is to possible serialise to JSON or XML, because they'r=
e
> > supported well
> > >>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>> other languages like c++, which won't read a java
> > serialised object,
> > >>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>> say for XML you generate objects via an XSD which by
> > default aren't
> > >>>>>>>>>>>>>>> serialisable, so you cannot simply add Serializable to
> the
> > object, as
> > >>>>>>>>>>>>>>> its
> > >>>>>>>>>>>>>>> generated at build.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Is this the problem we need to solve? If so:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> To get around this normally the tools that generate
> > objects for
> > >>>>>>>>>>>>>>> serialisation from schema such as XSD do support a way =
to
> > toggle or
> > >>>>>>>>>>>>>>> change
> > >>>>>>>>>>>>>>> the generation slightly for some common use cases.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> In case of XSD, where using jaxb it would be to add
> > something like the
> > >>>>>>>>>>>>>>> below to jaxb global bindings:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> <xs:annotation>
> > >>>>>>>>>>>>>>> <xs:appinfo>
> > >>>>>>>>>>>>>>> <jaxb:globalBindings generateIsSetMethod=3D"true">
> > >>>>>>>>>>>>>>> <xjc:serializable uid=3D"12343"/>
> > >>>>>>>>>>>>>>> </jaxb:globalBindings>
> > >>>>>>>>>>>>>>> </xs:appinfo>
> > >>>>>>>>>>>>>>> </xs:annotation>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> like wise if you are generating POJO's from a jsonschem=
a
> > using for say
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>> tool jsonschema2pojo  there is a toggle in the maven
> plugin
> > >>>>>>>>>>>>>>> serializable
> > >>>>>>>>>>>>>>> which you can switch to true.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Obviously if you hand crank your DTO Pojo's then it's a
> > case of simply
> > >>>>>>>>>>>>>>> add
> > >>>>>>>>>>>>>>> implement  Serializable to the class.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Cheers
> > >>>>>>>>>>>>>>> Mike
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Sent from my iPhone
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On 1 Jun 2017, at 06:57, Michael Andr=C3=A9 Pearce <
> > >>>>>>>>>>>>>>> michael.andre.pearce@me.com> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> we could but then it wouldn't work via jms api. Typical=
ly
> > if using jms
> > >>>>>>>>>>>>>>>> the only custom or specific broker object is the
> > connection factory
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>> rest you code to Jms.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Sent from my iPhone
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On 1 Jun 2017, at 04:10, Clebert Suconic <
> > clebert.suconic@gmail.com>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>> On Wed, May 31, 2017 at 10:47 PM Michael Andr=C3=A9 Pe=
arce <
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> michael.andre.pearce@me.com> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Jms api dictates class set in object message to be
> > serializable.
> > >>>>>>>>>>>>>>>>> We could make an extension. It could be an extra
> message
> > this
> > >>>>>>>>>>>>>>>>> actually.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On 31 May 2017, at 22:37, Timothy Nodine <
> > timgnodine@gmail.com>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Should the interface require the underlying class to =
be
> > Serializable?
> > >>>>>>>>>>>>>>>>> One use case might be to provide serialization to
> > classes that aren't
> > >>>>>>>>>>>>>>>>>> natively serializable.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Michael Andr=C3=A9 Pearce wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> To help discussion,
> > >>>>>>>>>>>>>>>>>>>> A very very basic implementation just to simulate
> the
> > idea.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > https://github.com/michaelandrepearce/activemq-artemis/tree/
> > >>>>>>>>>>>>>>>>>> CustomSerialisation
> > >>>>>>>>>>>>>>>> <
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > https://github.com/michaelandrepearce/activemq-artemis/tree/
> > >>>>>>>>>>>>>>>>>> CustomSerialisation
> > >>>>>>>>>>>>>>>> n.b. doesn=E2=80=99t fully compile is just pseudo impl=
, nor
> > doesn=E2=80=99t include
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> bits as discussed below like map/change type to a byt=
e
> > message for
> > >>>>>>>>>>>>>>>>>> compatibility, nor media type idea.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Cheers
> > >>>>>>>>>>>>>>>>>>>> Mike
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Clebert Suconic
> > >>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>> Tim Bish
> > >>>>>>>>>>>>> twitter: @tabish121
> > >>>>>>>>>>>>> blog: http://timbish.blogspot.com/
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Tim Bish
> > >>>>>>>>>>> twitter: @tabish121
> > >>>>>>>>>>> blog: http://timbish.blogspot.com/
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Tim Bish
> > >>>>>>>> twitter: @tabish121
> > >>>>>>>> blog: http://timbish.blogspot.com/
> > >>>>>>>>
> > >>>>>> --
> > >>>>>> Tim Bish
> > >>>>>> twitter: @tabish121
> > >>>>>> blog: http://timbish.blogspot.com/
> > >>>>>>
> > >>>>
> > >>>> --
> > >>>> Tim Bish
> > >>>> twitter: @tabish121
> > >>>> blog: http://timbish.blogspot.com/
> > >>>>
> > >>
> > >>
> > >>
> > >> --
> > >> Clebert Suconic
> > >
> >
> > --
> Clebert Suconic
>

--001a113ec1e4e87d940550f6c07d--