[feedhenry-dev] [Feedhenry-raincatcher] [MCP] Proposal for file storage service

Mon Oct 16 10:02:08 UTC 2017

Thanks of response

 > 1) Are you already decided on GridFS?

We will abstract from actual storage, similar how sync abstract from the
database solution.
Gridfs will be just provided as default implementation. We need to have
something that will work outside the box)

> 2) Is there a comparison you have done on different store types?

Server side will provide interface so any possible storage can be used.
We trying to focus on resolving file storage (offline sync) problem on the
mobile.
Server side is open and for the moment we may want to use something that is
already available for RainCatcher developers (GridFS)

> Have you looked into any kubernetes addons? e.g. Minio
https://docs.minio.io/

That may be added later as alternative implementation along with other like
NFS, Ceph.
This will fit perfectly to interface we going to build. Target is to get
something out there as spike, while still meeting RainCatcher functional
requirements.

> How it could fit in nicely with the 5.x work is having Mobile
clients/libraries and examples for different platforms and languages.

We can provide only Javascript/Cordova initially. ReactNative later.

On Mon, Oct 16, 2017 at 10:27 AM, John Frizelle <jfrizell at redhat.com> wrote:

> +1 on a file / object storage service and on Dave's comments around client
> libs. Under the 5.x model, we are developing stand alone libs for each
> service, but with some level of common structure (still TBD I think - it's
> basically a plugin architecture client side for passing config from the
> core module to each "plugin" at startup)
>
> On the server side storage engine side, my ask is that you look at ceph
> and gluster as potential storage engines - this would help advance the 5.x
> integration objectives. I know that the folks on the ops team have looked
> at these in quite a bit of detail, so should have some good insights to
> share.
>
> Cheers,
> John.
>
>
>
> --
> John Frizelle
> Chief Architect, Red Hat Mobile
> Consulting Engineer
>
> mobile: *+353 87 290 1644 <//+353872901644>*
> twitter:* @johnfriz*
> skype: *john_frizelle*
> mail: *jfrizell at redhat.com <jfrizell at redhat.com>*
>
>
>
>
> On 16 October 2017 at 09:57, David Martin <davmarti at redhat.com> wrote:
>
>> Hi Wojciech,
>>
>> An object storage sounds like a useful Mobile Service.
>> If the service has a docker image that doesn't require special
>> privileges, then it should be good for running on OpenShift.
>> How it could fit in nicely with the 5.x work is having Mobile
>> clients/libraries and examples for different platforms and languages.
>> e.g. Java & Kotlin for Android, Swift for iOS, js/browser for Cordova, js
>> for React Native.
>>
>> Are you already decided on GridFS?
>> Is there a comparison you have done on different store types?
>>
>> Have you looked into any kubernetes addons?
>> e.g. Minio https://docs.minio.io/
>>
>>
>> On 15 October 2017 at 18:31, Wojciech Trocki <wtrocki at redhat.com> wrote:
>>
>>> Hi lads
>>>
>>> I'm representing RainCatcher team.  <http://raincatcher.feedhenry.io/>
>>> As a team we are planning to work on the functionality that possibly may
>>> also exist as MCP service.
>>>
>>> *Introduction *
>>>
>>> Ability to store files (large binary data) is really common for the
>>> mobile applications.
>>> In most of the corporate use cases files cannot be saved on the public
>>> storage clouds like ICloud, Google drive etc.
>>> Previous versions of RHMAP had unofficial version of the file storage
>>> template that was widely used.
>>>
>>> Adding file storage as service will directly address common problem for
>>> most of the *corporate* *mobile* developers.
>>> Ability to use file storage service behind Keycloak service may help to
>>> validate security use cases.
>>>
>>> *Technical details:*
>>>
>>> Service will consist of the server side file server (similar to sync
>>> service).
>>> Implementation will be delivered in TypeScript. Storage will use GridFS
>>> by default, but it will be swappable by using interface.
>>> Additionally service will provide client (Cordova for the moment but we
>>> may support ReactNative in future)
>>>
>>> *Is this service useful/interesting for MCP team?*
>>>
>>> *RainCatcher Community request:*
>>> https://www.redhat.com/archives/feedhenry-raincatcher/2017-O
>>> ctober/msg00023.html
>>>
>>> *Context*
>>>
>>> As a team we need to deliver File/Image storage functionality, but also
>>> make sure that it will be usable even outside RainCatcher solution.
>>> I have read about and tried MCP for the last couple days and it looks
>>> really interesting.
>>> I'm working now (in my spare time) on spiking integration for
>>> RainCatcher project with MCP.
>>> Focusing mostly on using external sync and Keycloak service.
>>> As  a team we will widely benefit from MPC (it will simplify our
>>> OpenShift deployment).
>>> Additionally team can upskill in OpenShift and MCP while delivering this
>>> service.
>>>
>>> *Jira epic:*
>>> https://issues.jboss.org/browse/RAINCATCH-1346
>>>
>>> Regards
>>> --
>>>
>>> WOJCIECH TROCKI
>>>
>>> _______________________________________________
>>> Feedhenry-raincatcher mailing list
>>> Feedhenry-raincatcher at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>
>>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (feedhenry, mobile-internal)
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>

-- 

WOJCIECH TROCKI

Red Hat Mobile <https://www.redhat.com/>

IM: wtrocki
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171016/d14fe871/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171016/d14fe871/attachment.png>