kthomas_vh joined the chat room. kthomas_vh kthomas_vh left the chat room. kthomas_vh SendQ exceeded This-Alex|Ghost joined the chat room. This-Alex|Ghost This-Alex left the chat room. This-Alex Read error: 104 (Connection reset by peer) ipwa joined the chat room. ipwa MarkT joined the chat room. MarkT bredgar joined the chat room. bredgar ProLoser|Work sup ladies This-Alex|Ghost looks for the ladies ProLoser|Work lol you /just/ missed them bredgar is there still a meeting today? This-Alex|Ghost yeah bredgar what time ProLoser|Work now ? rcross hey guys This-Alex|Ghost yeah ryan was catching 40 winks though he might've gone over bredgar ok rcross ;) so, i'm just pulling up the items from last time This-Alex|Ghost :p This-Alex|Ghost is now known as This-Alex. This-Alex This-Alex|Ghost Timothee is just lurking rcross we've got -security analysis, patch review/testing, website issues, and possibly themes plus, i figured we'd shoudl discuss the plugin issues that bredgar brought up This-Alex I haven't got much time so I'd just like to say a few points rcross waves at Timothee This-Alex There's currently no distinction between models and libraries rcross go ahead alex This-Alex And everything's kinda guesswork with finding files everything has to be registered in the big globals array ProLoser|Work Timothee is not a dev? This-Alex I think it was you bredgar who said pp need a rearchitecture? Timothee is at work and doesn't have time to participate today This-Alex ok bredgar sigh... yes there are some major deficiencies This-Alex Well I think it'd be good to consider changing the way things are laid out rcross This-Alex: before we go too far with this discussion, we've already agreed that we will do any rearchitecting/rewriting of the system in the next version This-Alex oki just putting it on the noticeboard :) bredgar I don't think we can release a proper plugin system in 0.8.5 it would be more of a PoC and not a real functional system rcross bredgar: i agree - but i thought that we could release a partial one at least bredgar well, we can, but any plugins that get developed are almost certain to need a major overhaul when we do 0.9, which is looking more and more likely to be a major code overhaul rcross i don't think that is unreasonable bredgar plus I don't think anyone will be able to develop any really useful plugins because of the deficiencies rcross i didn't expect to have backwards compatibility on those plugins anyways bredgar well, we can release what currently exists it works (kind of) and doesn't have any security issues ProLoser|Work i'm sorry to be sidetracked, but are the dates on the roadmap supposed to be 2009? bredgar yep ProLoser|Work okay just cheking wonders if he's still connected to the channel bredgar we might be able to hack the application logs to use a new get_image_url function (or whatever it's called) rcross so, do we still want to move ahead with the plugin system the way it is? rhoward joined the chat room. rhoward bredgar that way themes without the image for wiki/timetracker/etc. could still display an icon of some sort rcross sounds like a reasonable work around ProLoser|Work uh, how come you guys don't just remove inline images? bredgar I don't want to do anymore development on the plugin system the way it is. I'd rather go fix the core. ProLoser|Work: what do you mean? ProLoser|Work well put all images into the css, as much as can be done, anything that is purely appearance should be css anyways and not really exist in dom. this way you let the css rules specify the images, and if those developing themes want to use those they simply /dont/ overrride those rules both deliberately or on accident This-Alex ok g2g see you later This-Alex left the chat room. This-Alex ProLoser|Work provided i'm even in the ballpark of what the issue is. I just think when it comes to themeing if we give more control to the css and takeout inline code it would make it much easier, if they want to override current icons they just rewrite the css instead of needing to hack the actual markup bredgar i'm not sure I follow rcross bredgar: do think we can patch the core? bredgar well maybe ProLoser|Work uh well i am hoping i am addressing the issue, get_image_url is used for inline pictures right? <img> stuff? and you want to let themer's not have to worry about it? Timothee ProLoser|Work, bredgar is talking about the problem of special images for plugins rcross ProLoser|Work: this is basically how the theming "system" currently works, so any inline code that you find should be changed and posted as a patch in an issue ProLoser|Work: it was discussed on the mailing list Timothee bredgar: ProLoser|Work is talking about some work he wants to do on the CSS/theming side at least I think bredgar ProLoser|Work: in the application logs next to each entry there is an icon denoting what type of entry it is (milestone, message, comment, etc.) ProLoser|Work well hack the application logs to use a new get_image_url function seemed like it was also changing code and the themeing system, i thought i was offering a different solution bredgar the problem is that get_image_url() constructs the URL to that image based on the selected theme rcross ah, i see... and ProLoser|Work is suggesting that the CSS of the theme be used to define the image url ProLoser|Work ya so just take it out, those are li's right? bredgar ProLoser|Work: perhaps you are, but I freely admit that I don't understand much about CSS ProLoser|Work instead of hacking the function which seems to give you guys trouble, why not apply classes to each li? and not worry about the whole theme/image selection? yes ALL image urls should be in the css it would save you guys a LOT of pain and time i think bredgar okay, that sounds good to me, but that brings up the issue of plugins including new css to show their icons ProLoser|Work simple: more stylesheets bredgar either way, plugin writers (or users) have to worry about making themes work with the plugin rcross well, I agree with both of you - in reality, we should have a system that could default one way, but be over ridden ProLoser|Work rcross: you do that using a default theme have some skilled themer help us make a new default theme bredgar yeah, which brings up how to organize the plugins directory such that raw files under the directory are accessible to the end-user ProLoser|Work themers then make new stylesheets, they can override whatever they want and plugins can bring hteir own css files too bredgar right now, all MVC, helper and library code exists *outside* of the publicly accessible web root rcross yea, but bredgar brings up the issue of a having a default for a non-core plugin needing to insert their defaults into the system - every theme won't cater for every possible plugin bredgar same goes for plugins ProLoser|Work woulud it be a pain to ask plugin people who supply their own theme to put it into the theme's directory? or make some sort of installation function that simply copies it over if not existant? bredgar if you don't include all of a plugin's files under a single directory, then it makes it harder to clean up plugins during removal from the system ProLoser|Work sorry not the theme's directory, our default css or plugin skin directory bredgar you get left over files all over the place my goal for a plugin system is that everything for a particular plugin gets kept under a single directory ProLoser|Work you guys don't have uh rerouting easily employed in your app i take it? bredgar sure we have routing employed ProLoser|Work i still think in the long run putting a folder in css for plugins is a decent idea, and make 1 function to check for it's existence of the plugin to delete/create the corresponding css folder/file and this way you can employ multiple skins for plugins rcross in general, i think this highlights the major deficiency of the current system + architecture - which is the need for a url/path engine bredgar in fact, theres a very nice patch to create clean URLs instead of the mess that exists now ProLoser|Work i guess i kinda assumed you guys had some routing engine bredgar i, personally, hope someone commits that clean URL patch soon ;) ProLoser|Work but regaurdless i /STILL/ think taking out inline images helps you a lot, and it doesn't break plugins just yet rcross bredgar: that's not quite teh same as a comprehensive routing engine ProLoser|Work in fact plugins are free to include inline images rcross ok, how about this solution - its kind of the start of a theme engine i guess ProLoser|Work i haven't figured on the plugin aspect but relying on themes to ONLY be a css file and folder of images i think saves all the time you guys would have spent helping out themers aren't there themers around we can ask what they want/need? Timothee I didn't read everything, but could we rely on the Apache configuration to have access to the files in say /plugins/[whatevername of the plugin]/images/ ? in a RewriteRule kind of way maybe rcross basically, provide a "core.css" file that plugins can hook into. Then the core.css file basically aggregates all the plugin-provided css and loads it in the page. The theme css is loaded after it, thus allowing the theme to override things ProLoser|Work sounds good to me, creating a virtual css file based on plugins? rcross yep bredgar yes, we could install another rewrite rule that could potentially solve the situation rcross: I like that idea ProLoser|Work i think that's a great idea, it means no moving of files Timothee I suppose one problem is that it limits us in terms of webserver, doesn't it? rcross and my next point goes along with Timothee in that we should probably rewrite some of the rules so that certain plugin assets can be publically available well, we're already making apache a pre-req, so for now its not a big deal Timothee I know we officially support only Apache, but whatever we do, we need to keep in mind that there has to be a work around for other servers ProLoser|Work rcross: you can't have plugin designers employ some standardization? inside your plugin folder you MUSt include a styles.css file and you automatically generate based upon that? if the plugin exists check for the file and that's it? rcross however, whatever is currently used to limit things to the public directory can probably be modified - i'll have to dig into that though ProLoser|Work: yes - that's effectively what i was suggesting above bredgar and now we'd be making mod_rewrite a pre-req, too ProLoser|Work yes, i just mean do we need to bother with plugin assetss? Timothee that's true, but it could be something where somebody with another webserver could copy the plugin file somewhere public so that it works... basically, maybe not as clean but work-around-able :) bredgar I've never used a hosting provider, but some of them may not provide such an option Timothee anyway, I'm happy with my brilliant contribution, back to work for now ;-) rcross most hosts i've used have mod_rewrite available ProLoser|Work i work in cakephp and they rely entirely on mod_rewrite they have one workaround called pretty urls but i don't think it really does the job rcross ok, bredgar are you happy with the provided solution - we'll have to work out the details on the mailing list or in an issue que ? bredgar yes rcross so, can we use that to provide a reasonable plugin system (noting that we'll rewrite it properly next time) bredgar do we want to talk about security issues at all? rcross or are there other major deficiencies you want to bring up? yea - that was my next topic, just wanted to clear up this part first bredgar we'll leave the 'deficiencies' at that rcross ok - i know its not ideal - but i appreciate you working to make this happen next up - security bredgar n/p we still have XSRF issues example: go to your dashboard, select a project, click on the people tab, and click 'remove from project' on somebody you dislike rcross how much of them are based on underlying system issues? or can we generally plug them all bredgar we didn't get all of them last time well, we can plug that one in the same way we can probably plug most of them in the same way rcross ok bredgar but a better solution (I've been reading an OWASP book) is to include some token in the server-side session information on any page that leads to a DB change rcross i assume in the future we can build in some helper functions and such that help prevent this stuff, no? yea, i like that idea bredgar after following a link, the system should check to make sure that what it thinks is the correct token is indeed in the server-side session rcross i assume that would be stored in a cookie instead of in the url? bredgar doing that would eliminate the "click on this really cool link" type of attack yes, it would be stored server-side and then some second part would be sent to the user's cookie sort of an RSA public-private key type deal rcross k bredgar if the user is tricked into loading a malicious link, the system checks the server-side value against whatever is sent in the cookie I think, in that case, we rely on the browsers to make sure that one site can't read another site's cookies and we use a little intelligence on our end to make sure that certain token values only apply to certain pages eliminating the "inside the app" attack these changes are more aimed at a 0.9 release as they will be a significant addition to the code I think rcross basically a combination of tokens based on session, page, and user bredgar (and that's once I convince myself that my idea isn't vulnerable to attack) yes rcross ok, sounds good to me - lets log an issue about it for 0.9 and plug the other holes we find for now bredgar cool rcross since we're getting closer to the end, i'll throw this out there for ProLoser|Work ProLoser|Work yes rcross I think it would be good to have a new core theme, so i think it woudl be worth while to hold a theme competition or something like that to get a good one of course, we'll have to do it after the feature freeze so that we don't have to worry about breaking themes ProLoser|Work i agree, but i thought it might be advisable to work /with/ a skilled themer to see what they need at their disposal when it comes to control, to see if just images and css IS easy enough, and i also wanted to mention the naming convention i spoke of rgr plus if you guys don't mind perhaps by the feature freeze me and whoever helping can go through and remove whatever able inline images we can so that themers need to know what they can replace rcross ProLoser|Work: its enough for them for now - we'll be looking at potenitally implementing a proper theme engine down the line, but that won't change for this version. Only changes now will be any markup changes that make it easier for css-only theming Timothee there's somebody working on a new theme right now, it might be a good idea to see with him (I forgot his name though) rcross ProLoser|Work: now is the time to start making any changes to the themes ProLoser|Work rcross:changing markup for css only is what i refer to: removal of images and perhaps employment of standardized class/id names? rcross use the core default theme to reflect those changes in the css ProLoser|Work rcross: were you the individal (ryan?) who was working on conversion to jquery? bredgar that's rmmcue rcross ProLoser|Work: no, that is rmmcue (we're both ryan) rhoward rmccue. Err. bredgar sorry, rmccue ProLoser|Work would you guys mind if in addition to the removal of images I try to work in some class names at least if i can't change the ids? rcross sure ProLoser|Work i'm assuming i'll have to bring up other dom changes seperate for id changes and possible structure for discussion first rcross yea, just log issues for each of that and post a patch - then it is easier for us to discuss what is actually being changed and have reasons why ProLoser|Work rgr some are probably more patch-related but overall i hope it helps themers in th eend rcross Timothee: i think you brought up the issue of patch review/testing last time. Did you want to go over that quickly today? Timothee well... I mentioned that because we need to make a bigger effort to make sure patches are reviewed and tested I'm not sure what the solution is though one thing could be to invite people who post patches to mention the main points to test (kind of white box testing) rcross ProLoser|Work: maybe you can help here since you're more of a newbie - what would help you to review/test patches? i think that should generally be done anyways tim ProLoser|Work 1 sec rcross but good point bredgar hey, i gotta run fellas rcross ok, same time next week? ProLoser|Work uh Timothee see you! bredgar i'll catch up with you all later on the mailing list and issue queue yep, same time next week take care! rcross bye brett ProLoser|Work uh... if the patches were small changes or easy to employ bredgar left the chat room. bredgar ProLoser|Work like putting some sort of description that helps us gather how much /review/ it would take and how much it would likely break rcross ok Timothee and I talked about that at the first meeting, but maybe posting a once-a-month list of patches to focus on could help too ProLoser|Work # of lines changed, what layer it is (model/view/controller) and iunno something that at a glance we can appraise? or perhaps however you guys store patches you could organize by i think if you guys let the layer be specified it would help GREATLY, like a checkbox to the layers affected and # of lines too might give an /idea/ in how much work it takes to review does that make sense or help at all? rcross you realize that 1) you should be testing on a fresh set of code, not your live install adn 2) you can read the patch and see all those issues you mention? ProLoser|Work i haven't read many of the patches, sorry, didn't know what was involved, and yes i gather you should test on fresh code Timothee maybe something to add to either the forum or the doc could be a brief workflow on how to setup the testing (I wanted to do that but never got to it) rcross thats ok - i asked because you were new ProLoser|Work i just thought you were asking me how to help you guys feel more inclined to review patches, cuz i know those 2 things are what i would think about when going to review a patch rcross Timothee: like this review ProLoser|Work because view to me is something i may be more inclined to work with or would feel be easier to check/fix and might break less, or you may be an expert with the model layer, etc rcross err.. http://projectpier.org/patch/review ProLoser|Work how best can i get ahold of the themer/ryan? rcross you can use his contact page on the website Timothee yes, but maybe adding some technical details... something like "check out the SVN trunk, apply the patch..." blablabla but that review page is good too rcross Timothee: ok, would you be willing to write up something - even if its just a stub for people to contribute to Timothee I would be... please bug me if I don't though rcross ok Timothee I still owe you a doc about Eclipse from last year :) rcross i know :) Timothee (I don't even use Eclipse anymore) I did start the doc! rcross would emailing out the list of key issues be easier for you? Timothee I think it's almost finished... not necessarily. ProLoser|Work oh ya one last thing pssh nvm rcross ? ProLoser|Work i was gonna ask do you guys let people override your js files but i think it's a silly question rcross yea, i don't think so ProLoser|Work wait what? you don't really support people putting in their own js? rcross well, i don't think there is scope for it in the current plugin system so any custom js would be seperate plus, i don't think you can override js in the same way as css ProLoser|Work well that's sorta what i want to implement i /think/ but it's entirely jquery related, it won't affect the core or mean any file changes, however i have to look into that in jquery rcross well, start with the small things, then we can move onto that ProLoser|Work rgr, honestly it's kind of an irrelevent queestion but i have one for you guys: http://projectpier.org/node/1216 saw this post was looking for a ticket that i've seen which is identical to what i've wanted to do. if i wanted to make this more likely for you guys to consider/employ how should i go about it? i assume not make another ticket but i wanna kinda add to it grr, i think i just need to sit down with a themer and ryan to see how to go about this rcross a quick search of the issue queue reveals no listed issue about the jquery conversion, so just post it and start working. post a patch as you get started so people can help on the patch ProLoser|Work well one thing i thought to help you guys oh ya nvm back to work rcross yep, thanks for a good meeting gusy guys keep up the good work and we'll meet again next week