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

[John Frizelle]

+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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171016/8bc82b54/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/8bc82b54/attachment.png>