[Feedhenry-raincatcher] [Community Functionality] Image storage

Mon Oct 16 08:36:32 UTC 2017

Open questions:

*1) Should we support this functionality when testing on the browser?*

When running on the browser we can use different format (base64 URI) of the
images.
Due to fact that we running on the browser file api (cordova) is not
supported.
Previously we were saving encoded content to local storage.
If we going to implement that this functionality will help developers to
try out their interface without building mobile application.

*2) What security mechanisms we should use?*

Two options:

- Security tokens that expire
Really typical security mechanism that using tokens that expire over the
time.
This allows people to share pictures/files with unauthenticated users.

- Any security mechanism that is currently used in application.
Keycloak/Passport.js - configurable by interface on the client and by using
protect interface on the server.

On Fri, Oct 13, 2017 at 6:05 PM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> I have created Jira tickets to implement this feature.
> Feel free to continue and comment directly in the Jira EPIC:
>
> https://issues.jboss.org/browse/RAINCATCH-1346
>
> Individual tickets are public, but only visible for users logged into jira.
>
> You can see them also using filter:
> https://issues.jboss.org/issues/?filter=-3&jql=%22Epic%20Link%22%20%20%3D%
> 20RAINCATCH-1346
>
>
> On Fri, Oct 13, 2017 at 5:59 PM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
>> > I think that this client should be split in at least two..
>>
>> I agree but, actual photoClient will be pure cordova plugin wrapper.
>> We can leverage types (this will be done in TypeScript) and have both as
>> abstractions.
>> This will help us to abstract both from each other.
>> Two clients are hard to document and support in future (versioning etc.)
>> I think the best way will be to have generic file client and extension to
>> this client that will be image specific.
>>
>> Finished investigating that case.
>>
>> WDYT?
>>
>>
>> On Fri, Oct 13, 2017 at 11:02 AM, Austin Cunningham <aucunnin at redhat.com>
>> wrote:
>>
>>> +1 for two separate modules.
>>>
>>> On 13 October 2017 at 10:43, Jameel Briones <jbriones at redhat.com> wrote:
>>>
>>>> +1. Agree with Paolo to separate it into two for reusability :)
>>>>
>>>> JAMEEL BRIONES
>>>>
>>>> ASSOCIATE SOFTWARE ENGINEER
>>>>
>>>> Red Hat Mobile
>>>>
>>>> <https://www.redhat.com/>
>>>>
>>>> Communications House, Cork Road
>>>>
>>>> Waterford City, Ireland X91NY33
>>>>
>>>> jbriones at redhat.com
>>>> <https://red.ht/sig>
>>>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>>>>
>>>> On Fri, Oct 13, 2017 at 9:49 AM, Darach Cawley <dcawley at redhat.com>
>>>> wrote:
>>>>
>>>>> This is a really good feature!
>>>>>
>>>>> On Thu, Oct 12, 2017 at 4:43 PM, Wojciech Trocki <wtrocki at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Following email contains proposition for new RainCatcher
>>>>>> functionality.
>>>>>> Contents of this email will be also moved to public jira and open for
>>>>>> discussion.
>>>>>>
>>>>>> *Introduction *
>>>>>>
>>>>>> RainCatcher users can build processes using steps.
>>>>>> When working with the steps results are saved as JSON file in
>>>>>> workorders.
>>>>>>
>>>>>> There are some situations when saving data in JSON format may not be
>>>>>> efficient.
>>>>>> For example binary files like images/pdfs needs to be encoded and can
>>>>>> lead to really big JSON payloads.
>>>>>>
>>>>>> *Top Level Functionality*
>>>>>>
>>>>>> RainCatcher as solution should support file (initially photos only)
>>>>>> upload that can be used when building steps.
>>>>>> Developers should be able to build their steps that can interact with
>>>>>> the files.
>>>>>> Server side should support file storage using interface - storage
>>>>>> agnostic.
>>>>>>
>>>>>> [image: Inline image 1]
>>>>>>
>>>>>>
>>>>>>
>>>>>> App flow
>>>>>>
>>>>>> 1. Step can use client api to create photo requests.
>>>>>> 2. As result client is calling camera plugin and photo is stored in
>>>>>> local storage.
>>>>>> 3. Step retrieves link to local file that contains image
>>>>>>
>>>>>> File Sync flow
>>>>>>
>>>>>> 1. All files that are created are put on sync queue.
>>>>>> Queue supports two types of sync (syncing local file, fetching file
>>>>>> from server)
>>>>>> 2.1 When online, files are synced to server
>>>>>> 2.2 When online, files are fetched from server. Step is notified and
>>>>>> retrieves link to new file.
>>>>>> 3. When offline queue is holding reference.
>>>>>> Queue needs to be persisted to survive application restarts.
>>>>>>
>>>>>> Note: Sync implementation will not use FeedHenry Sync.
>>>>>>
>>>>>> *Client side support*
>>>>>>
>>>>>> Client side (plain javascript) will contain queue implementation that
>>>>>> will interact with the cordova network state plugin.
>>>>>> Queue will hold references to local file and sync them when online.
>>>>>> Client will interact with the cordova camera plugin.
>>>>>> Client will be available as separate npm module that can be required
>>>>>> by any step implementation.
>>>>>>
>>>>>> *Server side support*
>>>>>>
>>>>>> New module that will expose file upload/download api.
>>>>>>
>>>>>> Proposed api endpoints
>>>>>>
>>>>>> *GET /api/files/{ID}* - retrieve specific file
>>>>>> *POST /api/files* - create file
>>>>>>
>>>>>> Endpoints will be used by client to sync needed files
>>>>>>
>>>>>> *Functional requirements*
>>>>>>
>>>>>> Both client and server should be configurable:
>>>>>>
>>>>>> - supporting different storage locations and other cordova parameters
>>>>>> like thumbnails support etc.
>>>>>> - supporting different storage engines on the server (interface)
>>>>>>
>>>>>> *Examples*
>>>>>>
>>>>>> Example step will be provided that will implement file sync
>>>>>> functionality
>>>>>>
>>>>>> *Relation to Beta Version functionality*
>>>>>>
>>>>>> Provided API in beta was missing required functionalities like full
>>>>>> offline support, configurable authentication etc.
>>>>>> With that in mind I personally suggest to not reuse any of the
>>>>>> functionalities from previous versions.
>>>>>>
>>>>>> *Notes*
>>>>>>
>>>>>> As this functionality is not WFM specific I suggest to done it in the
>>>>>> way so it will be reusable by others who wants to implement Cordova offline
>>>>>> file sync.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> --
>>>>>>
>>>>>> WOJCIECH TROCKI
>>>>>>
>>>>>> Red Hat Mobile <https://www.redhat.com/>
>>>>>>
>>>>>> IM: wtrocki
>>>>>> <https://red.ht/sig>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Darach Cawley
>>>>>
>>>>> Senior Consultant
>>>>>
>>>>> Red Hat Mobile
>>>>>
>>>>> dcawley at redhat.com     T: 051810130     IM: dcawley
>>>>>
>>>>> www.redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Austin Cunningham
>>>
>>> Associate Software Engineer - Mobile
>>>
>>> Red Hat Mobile <https://www.redhat.com>
>>>
>>> Communications House, Cork Road, Waterford X91NY33
>>>
>>> Ireland
>>>
>>> aucunnin at redhat.com
>>> <https://red.ht/sig>
>>>
>>>
>>>
>>> _______________________________________________
>>> Feedhenry-raincatcher mailing list
>>> Feedhenry-raincatcher at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>
>>>
>>
>>
>> --
>>
>> WOJCIECH TROCKI
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>>
>
>
>
> --
>
> WOJCIECH TROCKI
>
> Red Hat Mobile <https://www.redhat.com/>
>
> IM: wtrocki
> <https://red.ht/sig>
>

-- 

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-raincatcher/attachments/20171016/0bc02d86/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 39853 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20171016/0bc02d86/attachment.png>