Hi Imesh, A huge -1 for this idea.
This is going to introduce the same issue we had before with Tooling splitting between Dev Studio and Browser providing different features, going out of sync at some point and different development guidelines. It took years to get out of that mess and to get the focus on tooling to build a unified tooling experience for the platform. If there are gaps in the Dev Studio based tooling the correct approach would be to allocate people and time required to fix the gap. Train people to expedite the development process. Taking shirtcut and introducing another tooling playform is not the way to go. It introduce further confusion for the customers to choose which is the correct tooling and what should be the accepted development process. This is the same issue we had before and you are trying to go back to the same mess again with this alternative tooling idea. So absolutely -1 for anything to suggest to take the focus away from unified tooling experience on one platform taking place right now. Thanks and Regards, Harshana On Friday, 22 July 2016, Imesh Gunaratne <[email protected]> wrote: > Hi All, > > According to an internal discussion we had, we thought of introducing > $subject for improving the overall tooling experience of WSO2 middleware. > The main goal of this effort is to build a lightweight, cross-platform, > attractive, user-oriented tooling platform with reusable visualization > components. > > This has several sub goals: > > - Implementing reusable tooling components which can be used for > building an unified IDE: > - This would be similar to WSO2 Carbon architecture and analytics > platform where we implement reusable components and build products by > aggregating them. > - Reusing visualization components in web based UIs > - Making the tooling platform available on the web/cloud > > To achieve this, we thought of implementing tooling components in HTML5, > CSS and JavaScript. This would allow us to make the tooling platform; > platform independent, reusable and web enabled. > > > *WSO2 JS Tooling Platform High Level Architecture* > > [image: Inline image 1] > On high level, the WSO2 JS tooling platform would have above components. > Out of these we would first start with the visualization component and try > to come up with a JS library which can provide features needed for > implementing product specific tooling components. > > > *WSO2 JS Tooling Platform Component Architecture* > [image: Inline image 3] > > According to the above concept, we would use existing JS frameworks such > as D3.js, Backbone and Lodash for implementing the core tooling framework. > In this model, D3.js will be used for utilizing basic features needed for > drawing shapes, Backbone will be used for implementing JavaScript > extendibility features (only using Model and View from its MVC > architecture) and finally Lodash will be used for utilizing utility > functions. > > On top of the core tooling framework a collection of tooling components > will be implemented according to WSO2 product requirements. Initially we > will be starting with the NextGen ESB (Integration Server) by implementing > a sequence diagramming and data mapper modules. > > The initial source code of this effort can be found in WSO2 Incubator [1]. > Please feel free to try this out and share your thoughts. > > [1] > https://github.com/wso2-incubator/js-tooling-framework > > Thanks > > -- > *Imesh Gunaratne* > Software Architect > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > -- Sent from Gmail Mobile for IPhone
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
