From mboxrd@z Thu Jan 1 00:00:00 1970 From: bluewind at xinu.at (Florian Pritz) Date: Fri, 10 Jan 2014 21:56:32 +0100 Subject: RFE: .so filters In-Reply-To: <20140110203652.GR7608@serenity.lan> References: <20140109225802.GM7608@serenity.lan> <20140110090639.GN7608@serenity.lan> <52D029F9.40805@xinu.at> <52D0520C.1070609@xinu.at> <20140110201144.GQ7608@serenity.lan> <52D0572E.7080607@xinu.at> <20140110203652.GR7608@serenity.lan> Message-ID: <52D05E80.4000800@xinu.at> On 10.01.2014 21:36, John Keeping wrote: >> Looks rather easy to slurp stdin (from http://www.lua.org/pil/21.1.html): > > Interesting. But I think it will be simpler from both side if the > interface is just a function call source_filter could potentially get a rather long input and might not need it all at once. If it can processes input line by line or similar it makes sense to support that by writing chunks rather than buffering everything. I believe we currently already buffer the file (ui-tree.c print_object() buf variable) before calling the source_filter, but keeping the possibility to change that later is good. Also slurping is not really that much harder than writing the function header so I don't see a benefit in adding buffering to the cgit code. Last but not least, it keeps the interface between "exec" and "lua" filters the same or at least rather similar. If you can call a lua script as if it was execed (setting argv) that would make the handler totally transparent, but faster. > The only thing I'm not sure about is how the specification of the filter > function works, given that I don't think we can call a complete Lua > script as a function. (I'm also assuming that the Lua script will be in > an external file and not stored inline in the CGit config). http://www.lua.org/pil/25.2.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: