Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Udara Rathnayake
On Tue, Sep 27, 2016 at 3:40 PM, Chandana Napagoda 
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?
>
​I think based on the use-case we have to decide on this.​


​Eg:- If the actual asset is downloadable, metadata+actual data object can
be stored​. At the same time one can provide a CDN link to download the
same object.

​From a store POV its good if we can provision both the capabilities.

>
> Does asset authoring(publisher) should be implemented with the store, or
> relevant product team should implement it based on their use case?
>
​If we are to discontinue publishing capabilities, at what point we do the
negotiation part between store and publisher?​ Are we to provide APIs to
create asset model then put the actual content etc ?

​Are we going to deviate from the current extension model?​


>
> Does store needs to support multi-tenancy or are we moving to the
> different tenant-based container approach?
>
​We should follow the same c5 based model, which is container per
tenant(correct me if i'm wrong). ​


>
> Regards,
> Chandana
>
> --
> *Chandana Napagoda*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.org
>
> *Email  :  chand...@wso2.com **Mobile : +94718169299
> <%2B94718169299>*
>
> *Blog  :http://cnapagoda.blogspot.com 
> | http://chandana.napagoda.com *
>
> *Linkedin : http://www.linkedin.com/in/chandananapagoda
> *
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,
UdaraR
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Danesh Kuruppu
Hi all,

In case If we are going for generic store framework, framework should
capable of retrieving asset metadata from any source (since asset metadata
is maintained differently by each product) by extending metadata retrieval
logic for each asset type.
and for assets searching, I think searching logic should be a separate
reusable component, not a part of store framework. because it is not only
used by store UI, but also for remote api calls.
For example, API searching can also be a used in APIM Rest API call.

Thanks
Danesh

On Tue, Sep 27, 2016 at 4:23 PM, Udara Rathnayake  wrote:

>
>
> On Tue, Sep 27, 2016 at 3:40 PM, Chandana Napagoda 
> 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?
>>
> ​I think based on the use-case we have to decide on this.​
>
>
> ​Eg:- If the actual asset is downloadable, metadata+actual data object can
> be stored​. At the same time one can provide a CDN link to download the
> same object.
>
> ​From a store POV its good if we can provision both the capabilities.
>
>>
>> Does asset authoring(publisher) should be implemented with the store, or
>> relevant product team should implement it based on their use case?
>>
> ​If we are to discontinue publishing capabilities, at what point we do the
> negotiation part between store and publisher?​ Are we to provide APIs to
> create asset model then put the actual content etc ?
>
> ​Are we going to deviate from the current extension model?​
>
>
>>
>> Does store needs to support multi-tenancy or are we moving to the
>> different tenant-based container approach?
>>
> ​We should follow the same c5 based model, which is container per
> tenant(correct me if i'm wrong). ​
>
>
>>
>> Regards,
>> Chandana
>>
>> --
>> *Chandana Napagoda*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.org
>>
>> *Email  :  chand...@wso2.com **Mobile : +94718169299
>> <%2B94718169299>*
>>
>> *Blog  :http://cnapagoda.blogspot.com 
>> | http://chandana.napagoda.com *
>>
>> *Linkedin : http://www.linkedin.com/in/chandananapagoda
>> *
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
> UdaraR
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Nuwan Dias
Do we really need a Store Framework for C5? 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?

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 
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 **Mobile : +94718169299
> <%2B94718169299>*
>
> *Blog  :http://cnapagoda.blogspot.com 
> | http://chandana.napagoda.com *
>
> *Linkedin : 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


Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Selvaratnam Uthaiyashankar
On Tue, Sep 27, 2016 at 6:14 PM, Nuwan Dias  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.



> 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.



>
> 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 
> 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 **Mobile : +94718169299
>> <%2B94718169299>*
>>
>> *Blog  :http://cnapagoda.blogspot.com 
>> | http://chandana.napagoda.com *
>>
>> *Linkedin : 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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Nuwan Dias
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  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.

>
>
>> 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.

>
>
>
>>
>> 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 
>> 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 **Mobile : +94718169299
>>> <%2B94718169299>*
>>>
>>> *Blog  :http://cnapagoda.blogspot.com
>>>  | http://chandana.napagoda.com
>>> *
>>>
>>> *Linkedin : 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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Selvaratnam Uthaiyashankar
On Tue, Sep 27, 2016 at 6:47 PM, Nuwan Dias  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  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 
>>> 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 **Mobile :
 +94718169299 <%2B94718169299>*

 *Blog  :http://cnapagoda.blogspot.com
  | http://chandana.napagoda.com
 *

 *Linkedin : 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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread SajithAR Ariyarathna
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  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  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 
 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 **Mobile :
> +94718169299 <%2B94718169299>*
>
> *Blog  :http://cnapagoda.blogspot.com
>  | http://chandana.napagoda.com
> *
>
> *Linkedin : 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 E

Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Chandana Napagoda
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.

Regards,
Chandana


On Tue, Sep 27, 2016 at 8:01 PM, SajithAR Ariyarathna 
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  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  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 
> 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 **Mobile :
>> +94718169299 <%2B94718169299>*
>>
>> *Blog  :http://cnapagoda.blogspot.com
>>  | http://chandana.napagoda.com
>> *
>>
>

Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread Nuwan Dias
On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda 
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 
> 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  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  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 min

Re: [Architecture] Store framework for C5 based Products

2016-09-27 Thread SajithAR Ariyarathna
>
> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda 
>  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  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  wrote:

>
>
> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda 
> 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 
>> 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  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  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.



>

Re: [Architecture] Store framework for C5 based Products

2016-09-28 Thread Chathura Ekanayake
If we are not storing trivial artifacts, it is very difficult to use a
common UI for store and especially for publisher. If a store framework is
used, we end up extending it and in many situations it can become more
complex than developing a new UI. Therefore, I agree with Nuwan and
SajithAR that we should focus on reusable UIs only for parts that can be
used as it is, or with minimal modifications such as login, user
management, etc.

- Chathura

On Wed, Sep 28, 2016 at 11:57 AM, SajithAR Ariyarathna 
wrote:

> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda 
>> 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  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  wrote:
>
>>
>>
>> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda 
>> 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 >> > 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  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  wrote:
>>>
 Do we really need a Store Framework for C5?

>>>
>>>
>>> May be store framework is a wrong terminology, but t

Re: [Architecture] Store framework for C5 based Products

2016-09-28 Thread Afkham Azeez
On Wed, Sep 28, 2016 at 3:27 PM, Chathura Ekanayake 
wrote:

> If we are not storing trivial artifacts, it is very difficult to use a
> common UI for store and especially for publisher. If a store framework is
> used, we end up extending it and in many situations it can become more
> complex than developing a new UI. Therefore, I agree with Nuwan and
> SajithAR that we should focus on reusable UIs only for parts that can be
> used as it is, or with minimal modifications such as login, user
> management, etc.
>
>
+1
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture