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
