Hi all, You can find the action items as issues in the Goose project in [1] Github. Volunteers are always welcomed since this library has many improvements to make. Also @sameera can you add your suggestion - filter mechanism to inject before and after code to the Github.
Thanks. [1] - https://github.com/dulichan/goose.js/issues On Wed, Aug 28, 2013 at 12:02 AM, Srinath Perera <[email protected]> wrote: > +1 > > > On Tue, Aug 27, 2013 at 1:27 PM, Nuwan Bandara <[email protected]> wrote: > >> Excellent notes SameeraM >> >> Regards, >> /Nuwan >> >> >> On Tue, Aug 27, 2013 at 11:18 AM, Sameera Medagammaddegedara < >> [email protected]> wrote: >> >>> Hello everyone, >>> >>> The meeting minutes for the Jaggery Routing discussion are given below; >>> >>> *Objectives:* >>> The discussion centred around the implementation of Goose.js and its >>> viability as the de facto routing library for Jaggery. >>> >>> Goose.js is a routing library [5] for Jaggery that assits in the >>> creation of REST APIs. >>> >>> The areas examined included: >>> >>> - Viability of adopting Goose.js *(Questions Raised)* >>> - Optimizations to Goose.js *(Suggestions)* >>> - Ideas to improve Goose.js *(Suggestions and Ideas)* >>> - A plan of action on adopting Goose *(Action Items)* >>> >>> *Participants:* >>> >>> - *Jaggery Team*: (Nuwan, Ruchira , Manu, Praveena ,Buddhi and >>> Sameera) >>> - *Mobile Team: *(Chan [Dulitha] ,Shan and Dilshan ) >>> >>> *Questions Raised* >>> >>> - Does Goose.js have the capability to handle request parameters in >>> the url? >>> - E.g. localhost/test/users?name=dulitha >>> - *Answer:* Goose supports request parameters, path parameters >>> and request.body parameters but they are all available through a >>> single >>> object (ctx). The problem arrives when someone has the same key for >>> path >>> parameter and request parameter - then one is going to get replaced. >>> The >>> proposed architecture was to use three distinct objects - ctx.url, >>> ctx.path, ctx.body, ctx.files - as holders for the variables. This >>> will be >>> implemented as a configuration since in most cases the developer >>> using it >>> is intelligent to handle the duplication issue. Express.js part is not >>> necessary here. >>> - How do we specify routing logic in an external file? >>> - A single router instance is created in a front controller and >>> then passed to the subsequent scripts >>> - How do we handle situations such as api vs. /api where the slash >>> adds a different meaning to the url? >>> - *Answer:* route.get('',functio(ctxt) {}); >>> - This approach might not be the most readable >>> >>> *Suggestions:* >>> >>> - Encourage the use of a single Goose.js router instance >>> - Goose.js should have the ability to automatically load routing >>> logic from scripts given a target folder. The framework should be able to >>> iterate through the scripts and load them ,thus eliminating the need for >>> multiple require statements. (Ideally implemented using a configuration >>> block) >>> - The rendering logic should be abstracted away in order to ensure >>> that Goose.js handles only the routing logic. >>> - A suggestion was put forth to adopt a front controller pattern >>> which would eliminate the need to specify url mappings in the >>> jaggery.conf. >>> This would effectively equate Jaggery functionality with Node (barring >>> the >>> former been synchronous) >>> - An optimization step to the Goose.js involving a change to the >>> require logic. >>> - The scripts should be loaded once and only loaded again if the >>> time stamp has changed. >>> - Optimizations to the url passing >>> - Inspiration should be garnered from the algorithm used in the >>> existing URI matcher. >>> >>> *Action Items: >>> * >>> >>> 1. The Goose.js library should be made available as a P2 module like >>> Caramel. >>> 2. The Jaggery routing aspects should be moved to Goose.js by >>> *Enterprise >>> Store* *Milestone 5*. >>> 3. The Goose.js framework repository should be moved to the >>> jaggery-extensions repository and thus come under the purview of WSO2. >>> 4. A notification should be posted both on the Goose.js site and the >>> Jaggery site offering it up as an alternative to the URI matcher >>> 5. A research into the manner in which a package manager can be >>> implemented for Jaggery modules should be carried out >>> - *Possible Options:* >>> - An NPM style package management tool using a central repository of >>> modules >>> - A plug-in mechanism at the jaggery.conf level >>> - The use of GitHub modules (Eliminating the need to have the >>> Goose.js library as a >>> 6. Augment more features into the URI matcher from the URI >>> Matcher specification [2]. >>> >>> >>> *Ideas* >>> >>> - A filtering mechanism used to inject logic before routes >>> - An augmentation to Goose.js in the form of a middle-ware approach >>> similar to connect.js where logic can be "plugged-in" at specific points >>> of >>> execution. >>> >>> >>> >>> *References* >>> [1] Express.js,A web application framework for NodeJS ,url: >>> http://expressjs.com/ >>> [2] URI Template specification, url : http://tools.ietf.org/html/rfc6570 >>> [3] NPM, Node Package Manager, url: https://npmjs.org/ >>> [4] Connect, A middlware framework for NodeJS , url: >>> http://www.senchalabs.org/connect/ >>> [5] Goose.js, A routing framework for Jaggery, url: >>> https://github.com/dulichan/goose.js >>> >>> >>> >>> Thank You, >>> Sameera >>> >> >> >> >> -- >> *Thanks & Regards, >> >> Nuwan Bandara >> Technical Lead; **WSO2 Inc. * >> *lean . enterprise . middleware | http://wso2.com * >> *blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 763 >> 9629 >> * >> <http://www.nuwanbando.com/> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://people.apache.org/~hemapani/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulithawijewantha.com * * ~Blog blog.dulithawijewantha.com<http://dulichan.github.io/chan/> * * ~Twitter @dulitharw <https://twitter.com/dulitharw>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
