+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
