[Feedhenry-raincatcher] Renaming Raincatcher packages

Wed Feb 8 22:18:08 UTC 2017

On Wed, Feb 8, 2017 at 4:52 PM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> Sorry for not being clear. I mean RainCatcher framework consumers - mobile
> developers etc.
>
>
In that case having them clone and edit the Raincatcher modules to extend
the framework is wrong.

There is no right way to do that, any project based on that model is doomed
to fail.

Ahem, with that out of my system.

The reason this is not what we should encourage our users to do is that
when we release updates to Raincatcher the responsibility of back porting
those those updates will be on the end developers.  Suddenly keeping their
Raincatcher modules up to date becomes a massive amount of work that won't
get done.  If we uncover severe bugs (such as security bugs) then getting
out users to update their dependencies is of the utmost importance.  If
updating their dependencies requires rewriting their modules for trivial
changes, then they won't do it for important changes either.

The correct way to fix this is to use Angular's dependency injection
mechanisms to override the default Raincatcher behaviors with the user's
behaviors when this becomes necessary.  IE we must expose a rich API that
we support.  This is much easier to do in Angular 2 with Typescript than in
Angular 1 with JavaScript.

As a concrete example, let's take a Restful library on Android,
aerogear-android-pipe (https://github.com/aerogear/aerogear-android-pipe).

In order to make a RESTful call we use a fluent builder to build the
request and handle the response in a callback.  By default we use JSON
encoding.

PipeManager.config("developers", RestfulPipeConfiguration.class)
           .withUrl(new URL("http://www.server.com/developer"))
           .forClass(Developer.class);

Pipe<Developer> pipe = PipeManager.getPipe("developers");

pipe.read(new AbstractCallback<List<Developer>>() {
    @Override
    public void onSuccess(List<Developer> devs) {
        // Here you have a list of Developers made easy
    }

    @Override
    public void onFailure(Exception e) {
        // Oops! Something is wrong. Probably your internet is down :P
    }
});

Let's say that instead of using JSON the end developer has a requirement to
use an XML serialization format.  In this library the developer would
implement `RequestBuilder` and `ResponseParser` interfaces and supply them
to the library via PipeManager.config.  In the Raincatcher model the user
would download the pipe library and edit the code and deploy it herself.

However, there is currently a bug in AeroGear Pipe where the request is
buffered in memory before it is sent to the server.  If this were to be
fixed then users who used our API hooks to enable XML parsing would be able
to update their application dependency and rebuild their application.  This
is a very low risk operation which can even be automated.

However, if they had forked our library then they would be responsible for
1) noticing we had updated our library, 2) back porting our fix to their
fork, and 3) verifying that they back ported the fix correctly.  This is
much riskier and much harder to maintain because it requires more
engineering effort both at development time and during maintenance.

Wojciech Trocki
> Software Engineer, Red Hat Mobile
>
> On Wed, Feb 8, 2017 at 9:49 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Wed, Feb 8, 2017 at 4:44 PM, Wojciech Trocki <wtrocki at redhat.com>
>> wrote:
>>
>>> I was talking about this today with the team. Reducing number of
>>> repositories would clash with current development model where
>>> Raincacher developers should fork each module and make changes directly
>>> on the fork.
>>>
>>
>> By developers do you mean the rmad team or do you mean our end users?
>>
>>
>>
>>> We can merge some repos together, but only after we propose some
>>> alternative way to extend "modules". Team already started some small with
>>> refactoring to typescript, so we are on the good path.
>>> For now we can just pin the most important repositories to the page
>>> header. Making sure that repositories hare Readme would be a bonus.
>>> See bellow:
>>> https://github.com/feedhenry-raincatcher
>>>
>>> Wojciech Trocki
>>> Software Engineer, Red Hat Mobile
>>>
>>> On Wed, Feb 8, 2017 at 6:39 PM, Peter Darrow <pdarrow at redhat.com> wrote:
>>>
>>>> What do you guys think about reducing the number of repositories we're
>>>> dealing with? We could still publish individual RainCatcher modules to NPM
>>>> but it might help with visibility / overhead issue of having tons of small
>>>> repos. Just a thought!
>>>>
>>>> On Tue, Feb 7, 2017 at 4:40 PM, Summers Pittman <supittma at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 7, 2017 at 3:02 PM, David Martin <davmarti at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I'm a big fan of conventions.
>>>>>> This sounds like a good move.
>>>>>> +1
>>>>>>
>>>>>
>>>>> Ha! There's already a JIRA https://issues.jboss.org/browse/RAINCATCH-1
>>>>>
>>>>>
>>>>>
>>>>>> On 7 Feb 2017 19:06, "Summers Pittman" <supittma at redhat.com> wrote:
>>>>>>
>>>>>>> The Raincatcher packages are currently fh-wfm-$moduleName.  There
>>>>>>> are pull requests (ex https://github.com/feedhen
>>>>>>> ry-raincatcher/raincatcher-mediator/pull/8) to rename them to
>>>>>>> raincatcher-$moduleName.  This puts them inline with the project naming
>>>>>>> scheme.
>>>>>>>
>>>>>>> The linked pull request has some context around the name change.
>>>>>>>
>>>>>>> Should we pull the trigger on this rename as part of our refactoring?
>>>>>>>
>>>>>>> Summers
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Feedhenry-raincatcher mailing list
>>>>>>> Feedhenry-raincatcher at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Feedhenry-raincatcher mailing list
>>>>> Feedhenry-raincatcher at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Feedhenry-raincatcher mailing list
>>>> Feedhenry-raincatcher at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170208/c7eb7583/attachment.htm>