Salesforce operator

[Vlad Rozov <vr...@apache.org>]

Pramod,

Did you consider using CometD library directly? epm-connector is a thin layer on top of CometD and skipping it will allow you at least to resolve dependency on a snapshot version.

Thank you,

Vlad  

> On Jan 9, 2019, at 14:52, Thomas Weise <th...@apache.org> wrote:
> 
> Thanks for the actionable input.
> 
> I would suggest you try to contribute back. From my end I'm happy to
> support that as reviewer or in advisory capacity.
> 
> If multiple folks maintaining private forks were to contribute back, the
> cost equation was more attractive (you benefit from other contributions at
> the same time). That's how successful projects work (I happen to contribute
> to couple of them).
> 
> I think as part of that we will be able to identify and address perceived
> difficulties in contributions.
> 
> There is still the issue that Apex in its current form is hard to adopt
> (when you put yourself into the shoes of someone who just uses the binaries
> available here vs. some derivate of former support contract), but putting
> back enhancements and fixes developed as you go would be a good
> step forward.
> 
> Thomas
> 
> On Wed, Jan 9, 2019 at 2:35 PM Pramod Immaneni <pr...@gmail.com>
> wrote:
> 
>> We have a couple of operators notably a salesforce operator that I am
>> trying to get the necessary permissions at work to contribute. The
>> underlying salesforce client library (emp-connector) used by the operator
>> doesn't have a release yet so that is another reason slowing things down,
>> waiting to iron out issues. We are continuing to use apex and will likely
>> produce more operators during this year. There is also a plan to go to
>> kubernetes and that would likely result in the port being contributed to
>> the community or work done in collaboration with community members in the
>> open.
>> 
>> While trying to do this, I am facing a hard time trying to convince my
>> superiors that it is worthwhile for the company to contribute. They like
>> the technology and apex is in the stack but question whether the community
>> can work together and move forward, making their investment worthwhile.
>> They see discussions like this and others, where folks can't agree and move
>> forward, especially those who have been working on it for a long time, they
>> question if it is worth it.
>> 
>> Thanks
>> 
>> On Tue, Jan 8, 2019 at 10:17 PM Justin Mclean <ju...@classsoftware.com>
>> wrote:
>> 
>>> Hi,
>>> 
>>> My understanding is that there was some active development in private
>>> forks? If any of that code could be contributed back here then that could
>>> restate the project and generate interest. Does anyone know is that is
>> the
>>> case and if the people involved would be willing to do that?
>>> 
>>> I do agrees 6 months without a commit is a long time.
>>> 
>>> Thanks,
>>> Justin
>> 
>> 
>> 
>> --
>> Thanks,
>> Pramod
>> http://ts.la/pramod3443
>> 

Re: Salesforce operator

[Thomas Weise <th...@apache.org>]

Snapshot dependency in third-party repo is a bit problematic as we had seen
last year ;-)

But I would not consider it a blocker as long as the licensing is clear.


On Wed, Jan 9, 2019 at 6:40 PM Pramod Immaneni <pr...@gmail.com>
wrote:

> It would likely be easier to adapt to such an API change than
> developing/co-opting the protocol code, which would be throwaway work once
> there is a release anyway. Would be better to just manage with snapshot
> till there is a release. Or we could wait till there is a release. I can
> check with the devs if they have a plan to release a version soon.
>
> On Wed, Jan 9, 2019 at 6:29 PM Vlad Rozov <vr...@apache.org> wrote:
>
> > It is not only hosting on Apache or Maven Central that worries me. It is
> > also a snapshot version. My experience with hosting artifacts on maven
> > servers that are not mirrored by Maven central and a dependency on a
> > snapshot version are equally bad and both usually lead to broken builds.
> >
> > While protocol may change, API of the connector may change as well, so
> you
> > are not well guarded here by using salesforce library, IMO.
> >
> > Thank you,
> >
> > Vlad
> >
> > > On Jan 9, 2019, at 16:57, Pramod Immaneni <pr...@gmail.com>
> > wrote:
> > >
> > > Vlad,
> > >
> > > Not too worried about the dependency as the gating factor, it can
> always
> > be
> > > hosted on some maven server. Importantly it is developed by salesforce
> > > folks who will handle the specifics, which will allow portability in
> case
> > > the protocol evolves. It also handles the sf replay protocol,
> > reconnections
> > > and some login specific details that are helpful.
> > >
> > > Thanks
> > >
> > > On Wed, Jan 9, 2019 at 4:08 PM Vlad Rozov <vr...@apache.org> wrote:
> > >
> > >> Pramod,
> > >>
> > >> Did you consider using CometD library directly? epm-connector is a
> thin
> > >> layer on top of CometD and skipping it will allow you at least to
> > resolve
> > >> dependency on a snapshot version.
> > >>
> > >> Thank you,
> > >>
> > >> Vlad
> > >>
> > >>> On Jan 9, 2019, at 14:52, Thomas Weise <th...@apache.org> wrote:
> > >>>
> > >>> Thanks for the actionable input.
> > >>>
> > >>> I would suggest you try to contribute back. From my end I'm happy to
> > >>> support that as reviewer or in advisory capacity.
> > >>>
> > >>> If multiple folks maintaining private forks were to contribute back,
> > the
> > >>> cost equation was more attractive (you benefit from other
> contributions
> > >> at
> > >>> the same time). That's how successful projects work (I happen to
> > >> contribute
> > >>> to couple of them).
> > >>>
> > >>> I think as part of that we will be able to identify and address
> > perceived
> > >>> difficulties in contributions.
> > >>>
> > >>> There is still the issue that Apex in its current form is hard to
> adopt
> > >>> (when you put yourself into the shoes of someone who just uses the
> > >> binaries
> > >>> available here vs. some derivate of former support contract), but
> > putting
> > >>> back enhancements and fixes developed as you go would be a good
> > >>> step forward.
> > >>>
> > >>> Thomas
> > >>>
> > >>> On Wed, Jan 9, 2019 at 2:35 PM Pramod Immaneni <
> > >> pramod.immaneni@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> We have a couple of operators notably a salesforce operator that I
> am
> > >>>> trying to get the necessary permissions at work to contribute. The
> > >>>> underlying salesforce client library (emp-connector) used by the
> > >> operator
> > >>>> doesn't have a release yet so that is another reason slowing things
> > >> down,
> > >>>> waiting to iron out issues. We are continuing to use apex and will
> > >> likely
> > >>>> produce more operators during this year. There is also a plan to go
> to
> > >>>> kubernetes and that would likely result in the port being
> contributed
> > to
> > >>>> the community or work done in collaboration with community members
> in
> > >> the
> > >>>> open.
> > >>>>
> > >>>> While trying to do this, I am facing a hard time trying to convince
> my
> > >>>> superiors that it is worthwhile for the company to contribute. They
> > like
> > >>>> the technology and apex is in the stack but question whether the
> > >> community
> > >>>> can work together and move forward, making their investment
> > worthwhile.
> > >>>> They see discussions like this and others, where folks can't agree
> and
> > >> move
> > >>>> forward, especially those who have been working on it for a long
> time,
> > >> they
> > >>>> question if it is worth it.
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>>> On Tue, Jan 8, 2019 at 10:17 PM Justin Mclean <
> > justin@classsoftware.com
> > >>>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> My understanding is that there was some active development in
> private
> > >>>>> forks? If any of that code could be contributed back here then that
> > >> could
> > >>>>> restate the project and generate interest. Does anyone know is that
> > is
> > >>>> the
> > >>>>> case and if the people involved would be willing to do that?
> > >>>>>
> > >>>>> I do agrees 6 months without a commit is a long time.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Justin
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Thanks,
> > >>>> Pramod
> > >>>> http://ts.la/pramod3443
> > >>>>
> > >>
> > >> --
> > > Thanks,
> > > Pramod
> > > http://ts.la/pramod3443
> >
> >
>
> --
> Thanks,
> Pramod
> http://ts.la/pramod3443
>

Re: Salesforce operator

[Pramod Immaneni <pr...@gmail.com>]

It would likely be easier to adapt to such an API change than
developing/co-opting the protocol code, which would be throwaway work once
there is a release anyway. Would be better to just manage with snapshot
till there is a release. Or we could wait till there is a release. I can
check with the devs if they have a plan to release a version soon.

On Wed, Jan 9, 2019 at 6:29 PM Vlad Rozov <vr...@apache.org> wrote:

> It is not only hosting on Apache or Maven Central that worries me. It is
> also a snapshot version. My experience with hosting artifacts on maven
> servers that are not mirrored by Maven central and a dependency on a
> snapshot version are equally bad and both usually lead to broken builds.
>
> While protocol may change, API of the connector may change as well, so you
> are not well guarded here by using salesforce library, IMO.
>
> Thank you,
>
> Vlad
>
> > On Jan 9, 2019, at 16:57, Pramod Immaneni <pr...@gmail.com>
> wrote:
> >
> > Vlad,
> >
> > Not too worried about the dependency as the gating factor, it can always
> be
> > hosted on some maven server. Importantly it is developed by salesforce
> > folks who will handle the specifics, which will allow portability in case
> > the protocol evolves. It also handles the sf replay protocol,
> reconnections
> > and some login specific details that are helpful.
> >
> > Thanks
> >
> > On Wed, Jan 9, 2019 at 4:08 PM Vlad Rozov <vr...@apache.org> wrote:
> >
> >> Pramod,
> >>
> >> Did you consider using CometD library directly? epm-connector is a thin
> >> layer on top of CometD and skipping it will allow you at least to
> resolve
> >> dependency on a snapshot version.
> >>
> >> Thank you,
> >>
> >> Vlad
> >>
> >>> On Jan 9, 2019, at 14:52, Thomas Weise <th...@apache.org> wrote:
> >>>
> >>> Thanks for the actionable input.
> >>>
> >>> I would suggest you try to contribute back. From my end I'm happy to
> >>> support that as reviewer or in advisory capacity.
> >>>
> >>> If multiple folks maintaining private forks were to contribute back,
> the
> >>> cost equation was more attractive (you benefit from other contributions
> >> at
> >>> the same time). That's how successful projects work (I happen to
> >> contribute
> >>> to couple of them).
> >>>
> >>> I think as part of that we will be able to identify and address
> perceived
> >>> difficulties in contributions.
> >>>
> >>> There is still the issue that Apex in its current form is hard to adopt
> >>> (when you put yourself into the shoes of someone who just uses the
> >> binaries
> >>> available here vs. some derivate of former support contract), but
> putting
> >>> back enhancements and fixes developed as you go would be a good
> >>> step forward.
> >>>
> >>> Thomas
> >>>
> >>> On Wed, Jan 9, 2019 at 2:35 PM Pramod Immaneni <
> >> pramod.immaneni@gmail.com>
> >>> wrote:
> >>>
> >>>> We have a couple of operators notably a salesforce operator that I am
> >>>> trying to get the necessary permissions at work to contribute. The
> >>>> underlying salesforce client library (emp-connector) used by the
> >> operator
> >>>> doesn't have a release yet so that is another reason slowing things
> >> down,
> >>>> waiting to iron out issues. We are continuing to use apex and will
> >> likely
> >>>> produce more operators during this year. There is also a plan to go to
> >>>> kubernetes and that would likely result in the port being contributed
> to
> >>>> the community or work done in collaboration with community members in
> >> the
> >>>> open.
> >>>>
> >>>> While trying to do this, I am facing a hard time trying to convince my
> >>>> superiors that it is worthwhile for the company to contribute. They
> like
> >>>> the technology and apex is in the stack but question whether the
> >> community
> >>>> can work together and move forward, making their investment
> worthwhile.
> >>>> They see discussions like this and others, where folks can't agree and
> >> move
> >>>> forward, especially those who have been working on it for a long time,
> >> they
> >>>> question if it is worth it.
> >>>>
> >>>> Thanks
> >>>>
> >>>> On Tue, Jan 8, 2019 at 10:17 PM Justin Mclean <
> justin@classsoftware.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> My understanding is that there was some active development in private
> >>>>> forks? If any of that code could be contributed back here then that
> >> could
> >>>>> restate the project and generate interest. Does anyone know is that
> is
> >>>> the
> >>>>> case and if the people involved would be willing to do that?
> >>>>>
> >>>>> I do agrees 6 months without a commit is a long time.
> >>>>>
> >>>>> Thanks,
> >>>>> Justin
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thanks,
> >>>> Pramod
> >>>> http://ts.la/pramod3443
> >>>>
> >>
> >> --
> > Thanks,
> > Pramod
> > http://ts.la/pramod3443
>
>

-- 
Thanks,
Pramod
http://ts.la/pramod3443

Re: Salesforce operator

[Vlad Rozov <vr...@apache.org>]

It is not only hosting on Apache or Maven Central that worries me. It is also a snapshot version. My experience with hosting artifacts on maven servers that are not mirrored by Maven central and a dependency on a snapshot version are equally bad and both usually lead to broken builds.

While protocol may change, API of the connector may change as well, so you are not well guarded here by using salesforce library, IMO.

Thank you,

Vlad

> On Jan 9, 2019, at 16:57, Pramod Immaneni <pr...@gmail.com> wrote:
> 
> Vlad,
> 
> Not too worried about the dependency as the gating factor, it can always be
> hosted on some maven server. Importantly it is developed by salesforce
> folks who will handle the specifics, which will allow portability in case
> the protocol evolves. It also handles the sf replay protocol, reconnections
> and some login specific details that are helpful.
> 
> Thanks
> 
> On Wed, Jan 9, 2019 at 4:08 PM Vlad Rozov <vr...@apache.org> wrote:
> 
>> Pramod,
>> 
>> Did you consider using CometD library directly? epm-connector is a thin
>> layer on top of CometD and skipping it will allow you at least to resolve
>> dependency on a snapshot version.
>> 
>> Thank you,
>> 
>> Vlad
>> 
>>> On Jan 9, 2019, at 14:52, Thomas Weise <th...@apache.org> wrote:
>>> 
>>> Thanks for the actionable input.
>>> 
>>> I would suggest you try to contribute back. From my end I'm happy to
>>> support that as reviewer or in advisory capacity.
>>> 
>>> If multiple folks maintaining private forks were to contribute back, the
>>> cost equation was more attractive (you benefit from other contributions
>> at
>>> the same time). That's how successful projects work (I happen to
>> contribute
>>> to couple of them).
>>> 
>>> I think as part of that we will be able to identify and address perceived
>>> difficulties in contributions.
>>> 
>>> There is still the issue that Apex in its current form is hard to adopt
>>> (when you put yourself into the shoes of someone who just uses the
>> binaries
>>> available here vs. some derivate of former support contract), but putting
>>> back enhancements and fixes developed as you go would be a good
>>> step forward.
>>> 
>>> Thomas
>>> 
>>> On Wed, Jan 9, 2019 at 2:35 PM Pramod Immaneni <
>> pramod.immaneni@gmail.com>
>>> wrote:
>>> 
>>>> We have a couple of operators notably a salesforce operator that I am
>>>> trying to get the necessary permissions at work to contribute. The
>>>> underlying salesforce client library (emp-connector) used by the
>> operator
>>>> doesn't have a release yet so that is another reason slowing things
>> down,
>>>> waiting to iron out issues. We are continuing to use apex and will
>> likely
>>>> produce more operators during this year. There is also a plan to go to
>>>> kubernetes and that would likely result in the port being contributed to
>>>> the community or work done in collaboration with community members in
>> the
>>>> open.
>>>> 
>>>> While trying to do this, I am facing a hard time trying to convince my
>>>> superiors that it is worthwhile for the company to contribute. They like
>>>> the technology and apex is in the stack but question whether the
>> community
>>>> can work together and move forward, making their investment worthwhile.
>>>> They see discussions like this and others, where folks can't agree and
>> move
>>>> forward, especially those who have been working on it for a long time,
>> they
>>>> question if it is worth it.
>>>> 
>>>> Thanks
>>>> 
>>>> On Tue, Jan 8, 2019 at 10:17 PM Justin Mclean <justin@classsoftware.com
>>> 
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> My understanding is that there was some active development in private
>>>>> forks? If any of that code could be contributed back here then that
>> could
>>>>> restate the project and generate interest. Does anyone know is that is
>>>> the
>>>>> case and if the people involved would be willing to do that?
>>>>> 
>>>>> I do agrees 6 months without a commit is a long time.
>>>>> 
>>>>> Thanks,
>>>>> Justin
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Thanks,
>>>> Pramod
>>>> http://ts.la/pramod3443
>>>> 
>> 
>> --
> Thanks,
> Pramod
> http://ts.la/pramod3443

Re: Salesforce operator

[Pramod Immaneni <pr...@gmail.com>]

Vlad,

Not too worried about the dependency as the gating factor, it can always be
hosted on some maven server. Importantly it is developed by salesforce
folks who will handle the specifics, which will allow portability in case
the protocol evolves. It also handles the sf replay protocol, reconnections
and some login specific details that are helpful.

Thanks

On Wed, Jan 9, 2019 at 4:08 PM Vlad Rozov <vr...@apache.org> wrote:

> Pramod,
>
> Did you consider using CometD library directly? epm-connector is a thin
> layer on top of CometD and skipping it will allow you at least to resolve
> dependency on a snapshot version.
>
> Thank you,
>
> Vlad
>
> > On Jan 9, 2019, at 14:52, Thomas Weise <th...@apache.org> wrote:
> >
> > Thanks for the actionable input.
> >
> > I would suggest you try to contribute back. From my end I'm happy to
> > support that as reviewer or in advisory capacity.
> >
> > If multiple folks maintaining private forks were to contribute back, the
> > cost equation was more attractive (you benefit from other contributions
> at
> > the same time). That's how successful projects work (I happen to
> contribute
> > to couple of them).
> >
> > I think as part of that we will be able to identify and address perceived
> > difficulties in contributions.
> >
> > There is still the issue that Apex in its current form is hard to adopt
> > (when you put yourself into the shoes of someone who just uses the
> binaries
> > available here vs. some derivate of former support contract), but putting
> > back enhancements and fixes developed as you go would be a good
> > step forward.
> >
> > Thomas
> >
> > On Wed, Jan 9, 2019 at 2:35 PM Pramod Immaneni <
> pramod.immaneni@gmail.com>
> > wrote:
> >
> >> We have a couple of operators notably a salesforce operator that I am
> >> trying to get the necessary permissions at work to contribute. The
> >> underlying salesforce client library (emp-connector) used by the
> operator
> >> doesn't have a release yet so that is another reason slowing things
> down,
> >> waiting to iron out issues. We are continuing to use apex and will
> likely
> >> produce more operators during this year. There is also a plan to go to
> >> kubernetes and that would likely result in the port being contributed to
> >> the community or work done in collaboration with community members in
> the
> >> open.
> >>
> >> While trying to do this, I am facing a hard time trying to convince my
> >> superiors that it is worthwhile for the company to contribute. They like
> >> the technology and apex is in the stack but question whether the
> community
> >> can work together and move forward, making their investment worthwhile.
> >> They see discussions like this and others, where folks can't agree and
> move
> >> forward, especially those who have been working on it for a long time,
> they
> >> question if it is worth it.
> >>
> >> Thanks
> >>
> >> On Tue, Jan 8, 2019 at 10:17 PM Justin Mclean <justin@classsoftware.com
> >
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> My understanding is that there was some active development in private
> >>> forks? If any of that code could be contributed back here then that
> could
> >>> restate the project and generate interest. Does anyone know is that is
> >> the
> >>> case and if the people involved would be willing to do that?
> >>>
> >>> I do agrees 6 months without a commit is a long time.
> >>>
> >>> Thanks,
> >>> Justin
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> Pramod
> >> http://ts.la/pramod3443
> >>
>
> --
Thanks,
Pramod
http://ts.la/pramod3443