>
> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda <chand...@wso2.com>
>  wrote:
>  I believe that we should identify commonly used components and implement
> them in a generalized manner. So relevant product team can extend those
> components based on their requirements.

Agreed, this is the mitivation/goal of UUF.

On Wed, Sep 28, 2016 at 11:09 AM, Nuwan Dias <nuw...@wso2.com> wrote:

 My gut feeling is that if we go down this path, we will put a lot of
> effort/cycles to build a generic component/framework. Then we will again
> put a lot of effort to extend that component and try to build the specifics
> for the relevant Product Store. Which kind of doesn't make sense.

This is exactly my concern.

One approach we discussed early, is to develop a web app (e.g. APIM Store)
and identify what can be generalized and make them into generic UI
component alongside.

Thanks.


On Wed, Sep 28, 2016 at 11:09 AM, Nuwan Dias <nuw...@wso2.com> wrote:

>
>
> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda <chand...@wso2.com>
> wrote:
>
>> Hi,
>>
>> As per my understanding, within WSO2 products there should be some set of
>> components which are providing generalized and shared features to products
>> including searching, basic listing, login UI, etc. Otherwise most of the
>> product team have to duplicate their effort. Ex: IS portal, IoT, and APIM
>> teams have to write their searching components, and that will be a
>> duplicated effort. I believe that we should identify commonly used
>> components and implement them in a generalized manner. So relevant product
>> team can extend those components based on their requirements.
>>
>
> All these capabilities are addressed by APIs. Ex: In the case of listing
> APIs, what API Manager does it a GET /apis. Same for search. i.e GET
> /apis/search?name=xxx&version=1.0.0. So each product (in C5) will
> basically have its own APIs that perform these functionality. And these
> functionality (back-end) won't be shared, because how we fetch APIs and how
> we fetch Devices will be completely independent and there won't be anything
> that's shared between them.
>
> The only thing that looks common is is the rendering part. But even in
> that, different products will have different needs. Ex: API Manager will
> want to groups APIs into packages (products) and display on the listing
> page. It may have meta information that's specific to API Manager (Business
> Owner). So there are still many specifics to address in the rendering part.
> My gut feeling is that if we go down this path, we will put a lot of
> effort/cycles to build a generic component/framework. Then we will again
> put a lot of effort to extend that component and try to build the specifics
> for the relevant Product Store. Which kind of doesn't make sense. You also
> need to take into consideration the release dependencies, version
> incompatibilities, etc, etc. Isn't this the same thing we tried to do once
> with Enterprise Store?
>
>>
>> Regards,
>> Chandana
>>
>>
>> On Tue, Sep 27, 2016 at 8:01 PM, SajithAR Ariyarathna <sajit...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> Creating a reusable Store component was one of goals we had in our minds
>>> at UUF initial discussions. At that time there was couple of products APIM,
>>> AppM, EMM mobile store, GReg etc. that need a Store UI. So developing a
>>> generalized Store component was a requirement. However with the new product
>>> strategy there is not as many products (only APIM, IoT, IS)  that need a
>>> Store UI. I feel like their requirements are too broad and diverse, hence
>>> we might not be able to develop a generalized Store component. Instead of
>>> developing a Store component, we can develop other small component that are
>>> needed for a store e.g. SSO component, Social, Self-signup, user-mgt. This
>>> is just my opinion/gut feeling. We should discuss this thoroughly.
>>>
>>> Shall we setup a meeting for this?
>>>
>>> Thanks.
>>>
>>> On Tue, Sep 27, 2016 at 7:04 PM, Selvaratnam Uthaiyashankar <
>>> shan...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 27, 2016 at 6:47 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 27, 2016 at 6:31 PM, Selvaratnam Uthaiyashankar <
>>>>> shan...@wso2.com> wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Sep 27, 2016 at 6:14 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>>>
>>>>>>> Do we really need a Store Framework for C5?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> May be store framework is a wrong terminology, but there should be a
>>>>>> reusable store component written by using UUF.
>>>>>>
>>>>>
>>>>> So UUF itself is re-usable. We're going to build a Store component
>>>>> that's also re-usable using UUF. That's two levels of abstraction before 
>>>>> we
>>>>> get to the actual generalization. It sounds like too much abstraction to 
>>>>> me
>>>>> :). Unless there is a strong need, IMO we should just go by reusing what
>>>>> UUF offers and build our own Stores on that.
>>>>>
>>>>
>>>> I'll let UUF guys to answer this, but one of the requirement was to
>>>> create reusable components like store/login/dashboard using UUF.
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>> Rather, isn't it a UI framework (UUF) we need to build UIs? Apart
>>>>>>> from API-M and IoTS, are there any other products which need a Store?
>>>>>>>
>>>>>>
>>>>>> Store is needed in IS (end user portal, similar to AppM) as well.
>>>>>>
>>>>>
>>>>> The end user portal is a dashboard right? Its not really a Store.
>>>>>
>>>>
>>>> Part of end user portal is the store of applications available for the
>>>> user. Similar to app manager store with applications configured with SSO.
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Even if we come up with a Store Framework, I think the facilities it
>>>>>>> provides will be minimal isn't it? Since the products that use this 
>>>>>>> Store
>>>>>>> will have its own set of APIs for the back-end functionality, the only
>>>>>>> thing the Store UI would be doing is to call that set of APIs for the
>>>>>>> relevant functionality (ex: search API, list API). Therefore if we try 
>>>>>>> to
>>>>>>> list the generic functionality offered by the Store Framework, I feel 
>>>>>>> the
>>>>>>> functionality it provides will be minimal. And if that's true, then 
>>>>>>> there's
>>>>>>> really no point in building a Store Framework. The products better build
>>>>>>> their own Stores using the common UI framework based on a theme that's
>>>>>>> common across the platform.
>>>>>>>
>>>>>>> On Tue, Sep 27, 2016 at 3:40 PM, Chandana Napagoda <
>>>>>>> chand...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> While analyzing store requirements of C5 based products(IoT, APIM),
>>>>>>>> we have few areas to be clarified. Based on the current understanding, 
>>>>>>>> C5
>>>>>>>> based store will not be bound into existing governance aspects. This 
>>>>>>>> should
>>>>>>>> be a store framework with listing and searching capabilities.
>>>>>>>>
>>>>>>>> Should we consider generic metadata-based asset model for C5 based
>>>>>>>> Store?
>>>>>>>>
>>>>>>>> Does asset authoring(publisher) should be implemented with the
>>>>>>>> store, or relevant product team should implement it based on their use 
>>>>>>>> case?
>>>>>>>>
>>>>>>>> Does store needs to support multi-tenancy or are we moving to the
>>>>>>>> different tenant-based container approach?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Chandana
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Chandana Napagoda*
>>>>>>>> Associate Technical Lead
>>>>>>>> WSO2 Inc. - http://wso2.org
>>>>>>>>
>>>>>>>> *Email  :  chand...@wso2.com <chand...@wso2.com>**Mobile :
>>>>>>>> +94718169299 <%2B94718169299>*
>>>>>>>>
>>>>>>>> *Blog  :    http://cnapagoda.blogspot.com
>>>>>>>> <http://cnapagoda.blogspot.com> | http://chandana.napagoda.com
>>>>>>>> <http://chandana.napagoda.com>*
>>>>>>>>
>>>>>>>> *Linkedin : http://www.linkedin.com/in/chandananapagoda
>>>>>>>> <http://www.linkedin.com/in/chandananapagoda>*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nuwan Dias
>>>>>>>
>>>>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>>>>> email : nuw...@wso2.com
>>>>>>> Phone : +94 777 775 729
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> S.Uthaiyashankar
>>>>>> VP Engineering
>>>>>> WSO2 Inc.
>>>>>> http://wso2.com/ - "lean . enterprise . middleware"
>>>>>>
>>>>>> Phone: +94 714897591
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nuwan Dias
>>>>>
>>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>>> email : nuw...@wso2.com
>>>>> Phone : +94 777 775 729
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> S.Uthaiyashankar
>>>> VP Engineering
>>>> WSO2 Inc.
>>>> http://wso2.com/ - "lean . enterprise . middleware"
>>>>
>>>> Phone: +94 714897591
>>>>
>>>
>>>
>>>
>>> --
>>> Sajith Janaprasad Ariyarathna
>>> Software Engineer; WSO2, Inc.;  http://wso2.com/
>>> <https://wso2.com/signature>
>>>
>>
>>
>>
>> --
>> *Chandana Napagoda*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.org
>>
>> *Email  :  chand...@wso2.com <chand...@wso2.com>**Mobile : +94718169299
>> <%2B94718169299>*
>>
>> *Blog  :    http://cnapagoda.blogspot.com <http://cnapagoda.blogspot.com>
>> | http://chandana.napagoda.com <http://chandana.napagoda.com>*
>>
>> *Linkedin : http://www.linkedin.com/in/chandananapagoda
>> <http://www.linkedin.com/in/chandananapagoda>*
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>



-- 
Sajith Janaprasad Ariyarathna
Software Engineer; WSO2, Inc.;  http://wso2.com/
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to