[08:35am] kthomas_vh joined the chat room.
[08:38am] kthomas_vh left the chat room. (SendQ exceeded)
[08:43am] This-Alex|Ghost joined the chat room.
[08:47am] This-Alex left the chat room. (Read error: 104 (Connection reset by peer))
[08:52am] ipwa joined the chat room.
[09:09am] MarkT joined the chat room.
[09:24am] bredgar joined the chat room.
[09:24am] ProLoser|Work: sup ladies
[09:27am] • This-Alex|Ghost looks for the ladies
[09:28am] ProLoser|Work: lol
[09:28am] ProLoser|Work: you /just/ missed them
[09:29am] bredgar: is there still a meeting today?
[09:29am] This-Alex|Ghost: yeah
[09:30am] bredgar: what time
[09:30am] ProLoser|Work: now
[09:30am] ProLoser|Work: ?
[09:30am] rcross: hey guys
[09:30am] This-Alex|Ghost: yeah
[09:31am] This-Alex|Ghost: ryan was catching 40 winks
[09:31am] This-Alex|Ghost: though he might've gone over
[09:31am] bredgar: ok
[09:31am] rcross: ;)
[09:32am] rcross: so, i'm just pulling up the items from last time
[09:32am] This-Alex|Ghost: :p
[09:33am] This-Alex|Ghost is now known as This-Alex.
[09:33am] • Timothee is just lurking
[09:33am] rcross: we've got -security analysis, patch review/testing, website issues, and possibly themes
[09:34am] rcross: plus, i figured we'd shoudl discuss the plugin issues that bredgar brought up
[09:34am] This-Alex: I haven't got much time so I'd just like to say a few points
[09:34am] • rcross waves at Timothee
[09:34am] This-Alex: There's currently no distinction between models and libraries
[09:34am] rcross: go ahead alex
[09:35am] This-Alex: And everything's kinda guesswork with finding files
[09:35am] This-Alex: everything has to be registered in the big globals array
[09:35am] ProLoser|Work: Timothee is not a dev?
[09:35am] This-Alex: I think it was you bredgar who said pp need a rearchitecture?
[09:36am] • Timothee is at work and doesn't have time to participate today
[09:36am] This-Alex: ok
[09:36am] bredgar: sigh... yes there are some major deficiencies
[09:36am] This-Alex: Well I think it'd be good to consider changing the way things are laid out
[09:37am] 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
[09:37am] This-Alex: oki
[09:38am] This-Alex: just putting it on the noticeboard :)
[09:38am] bredgar: I don't think we can release a proper plugin system in 0.8.5
[09:38am] bredgar: it would be more of a PoC and not a real functional system
[09:39am] rcross: bredgar: i agree - but i thought that we could release a partial one at least
[09:39am] 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
[09:40am] rcross: i don't think that is unreasonable
[09:40am] bredgar: plus I don't think anyone will be able to develop any really useful plugins because of the deficiencies
[09:40am] rcross: i didn't expect to have backwards compatibility on those plugins anyways
[09:41am] bredgar: well, we can release what currently exists
[09:41am] bredgar: it works (kind of) and doesn't have any security issues
[09:41am] ProLoser|Work: i'm sorry to be sidetracked, but are the dates on the roadmap supposed to be 2009?
[09:41am] bredgar: yep
[09:41am] ProLoser|Work: okay just cheking
[09:44am] • ProLoser|Work wonders if he's still connected to the channel
[09:44am] bredgar: we might be able to hack the application logs to use a new get_image_url function (or whatever it's called)
[09:44am] rcross: so, do we still want to move ahead with the plugin system the way it is?
[09:44am] rhoward joined the chat room.
[09:44am] bredgar: that way themes without the image for wiki/timetracker/etc. could still display an icon of some sort
[09:45am] rcross: sounds like a reasonable work around
[09:46am] ProLoser|Work: uh, how come you guys don't just remove inline images?
[09:46am] bredgar: I don't want to do anymore development on the plugin system the way it is.  I'd rather go fix the core.
[09:46am] bredgar: ProLoser|Work: what do you mean?
[09:47am] 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
[09:47am] ProLoser|Work: both deliberately or on accident
[09:49am] This-Alex: ok g2g
[09:49am] This-Alex: see you later
[09:49am] This-Alex left the chat room.
[09:49am] 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
[09:49am] bredgar: i'm not sure I follow
[09:49am] rcross: bredgar: do think we can patch the core?
[09:50am] bredgar: well
[09:50am] bredgar: maybe
[09:50am] ProLoser|Work: uh well i am hoping i am addressing the issue, get_image_url is used for inline pictures right?
[09:50am] ProLoser|Work: <img> stuff? and you want to let themer's not have to worry about it?
[09:51am] Timothee: ProLoser|Work, bredgar is talking about the problem of special images for plugins
[09:51am] 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
[09:51am] rcross: ProLoser|Work: it was discussed on the mailing list
[09:51am] Timothee: bredgar: ProLoser|Work is talking about some work he wants to do on the CSS/theming side
[09:51am] Timothee: at least I think
[09:51am] 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.)
[09:52am] 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
[09:52am] bredgar: the problem is that get_image_url() constructs the URL to that image based on the selected theme
[09:53am] rcross: ah, i see... and ProLoser|Work is suggesting that the CSS of the theme be used to define the image url
[09:53am] ProLoser|Work: ya so just take it out, those are li's right?
[09:53am] bredgar: ProLoser|Work: perhaps you are, but I freely admit that I don't understand much about CSS
[09:53am] 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?
[09:53am] ProLoser|Work: yes
[09:53am] ProLoser|Work: ALL image urls should be in the css
[09:53am] ProLoser|Work: it would save you guys a LOT of pain and time i think
[09:54am] bredgar: okay, that sounds good to me, but that brings up the issue of plugins including new css to show their icons
[09:54am] ProLoser|Work: simple: more stylesheets
[09:54am] bredgar: either way, plugin writers (or users) have to worry about making themes work with the plugin
[09:54am] rcross: well, I agree with both of you - in reality, we should have a system that could default one way, but be over ridden
[09:54am] ProLoser|Work: rcross: you do that using a default theme
[09:55am] ProLoser|Work: have some skilled themer help us make a new default theme
[09:55am] bredgar: yeah, which brings up how to organize the plugins directory such that raw files under the directory are accessible to the end-user
[09:55am] ProLoser|Work: themers then make new stylesheets, they can override whatever they want
[09:55am] ProLoser|Work: and plugins can bring hteir own css files too
[09:55am] bredgar: right now, all MVC, helper and library code exists *outside* of the publicly accessible web root
[09:55am] 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
[09:55am] bredgar: same goes for plugins
[09:56am] ProLoser|Work: woulud it be a pain to ask plugin people who supply their own theme to put it into the theme's directory?
[09:56am] ProLoser|Work: or make some sort of installation function that simply copies it over if not existant?
[09:56am] 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
[09:56am] ProLoser|Work: sorry not the theme's directory, our default css or plugin skin directory
[09:56am] bredgar: you get left over files all over the place
[09:57am] bredgar: my goal for a plugin system is that everything for a particular plugin gets kept under a single directory
[09:57am] ProLoser|Work: you guys don't have uh rerouting easily employed in your app i take it?
[09:58am] bredgar: sure we have routing employed
[09:58am] 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
[09:58am] ProLoser|Work: and this way you can employ multiple skins for plugins
[09:58am] rcross: in general, i think this highlights the major deficiency of the current system + architecture - which is the need for a url/path engine
[09:58am] bredgar: in fact, theres a very nice patch to create clean URLs instead of the mess that exists now
[09:59am] ProLoser|Work: i guess i kinda assumed you guys had some routing engine
[09:59am] bredgar: i, personally, hope someone commits that clean URL patch soon ;)
[09:59am] ProLoser|Work: but regaurdless i /STILL/ think taking out inline images helps you a lot, and it doesn't break plugins just yet
[09:59am] rcross: bredgar: that's not quite teh same as a comprehensive routing engine
[09:59am] ProLoser|Work: in fact plugins are free to include inline images
[10:00am] rcross: ok, how about this solution - its kind of the start of a theme engine i guess
[10:00am] 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
[10:01am] ProLoser|Work: aren't there themers around we can ask what they want/need?
[10:01am] 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
[10:01am] 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
[10:02am] ProLoser|Work: sounds good to me, creating a virtual css file based on plugins?
[10:02am] rcross: yep
[10:02am] bredgar: yes, we could install another rewrite rule that could potentially solve the situation
[10:02am] bredgar: rcross: I like that idea
[10:02am] ProLoser|Work: i think that's a great idea, it means no moving of files
[10:03am] Timothee: I suppose one problem is that it limits us in terms of webserver, doesn't it?
[10:03am] 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
[10:03am] rcross: well, we're already making apache a pre-req, so for now its not a big deal
[10:04am] 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
[10:04am] 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?
[10:04am] 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
[10:04am] rcross: ProLoser|Work: yes - that's effectively what i was suggesting above
[10:05am] bredgar: and now we'd be making mod_rewrite a pre-req, too
[10:05am] ProLoser|Work: yes, i just mean do we need to bother with plugin assetss?
[10:05am] 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 :)
[10:05am] bredgar: I've never used a hosting provider, but some of them may not provide such an option
[10:05am] Timothee: anyway, I'm happy with my brilliant contribution, back to work for now ;-)
[10:05am] rcross: most hosts i've used have mod_rewrite available
[10:06am] ProLoser|Work: i work in cakephp and they rely entirely on mod_rewrite
[10:06am] ProLoser|Work: they have one workaround called pretty urls but i don't think it really does the job
[10:08am] 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
[10:08am] rcross: ?
[10:08am] bredgar: yes
[10:09am] rcross: so, can we use that to provide a reasonable plugin system (noting that we'll rewrite it properly next time)
[10:09am] bredgar: do we want to talk about security issues at all?
[10:09am] rcross: or are there other major deficiencies you want to bring up?
[10:09am] rcross: yea - that was my next topic, just wanted to clear up this part first
[10:10am] bredgar: we'll leave the 'deficiencies' at that
[10:10am] rcross: ok - i know its not ideal - but i appreciate you working to make this happen
[10:10am] rcross: next up - security
[10:10am] bredgar: n/p
[10:11am] bredgar: we still have XSRF issues
[10:11am] bredgar: example: go to your dashboard, select a project, click on the people tab, and click 'remove from project' on somebody you dislike
[10:11am] rcross: how much of them are based on underlying system issues? or can we generally plug them all 
[10:11am] bredgar: we didn't get all of them last time
[10:11am] bredgar: well, we can plug that one in the same way
[10:12am] bredgar: we can probably plug most of them in the same way
[10:12am] rcross: ok
[10:12am] 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
[10:13am] rcross: i assume in the future we can build in some helper functions and such that help prevent this stuff, no?
[10:13am] rcross: yea, i like that idea
[10:13am] 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
[10:14am] rcross: i assume that would be stored in a cookie instead of in the url?
[10:14am] bredgar: doing that would eliminate the "click on this really cool link" type of attack
[10:14am] bredgar: yes, it would be stored server-side and then some second part would be sent to the user's cookie
[10:14am] bredgar: sort of an RSA public-private key type deal
[10:15am] rcross: k
[10:15am] 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
[10:16am] bredgar: I think, in that case, we rely on the browsers to make sure that one site can't read another site's cookies
[10:16am] bredgar: and we use a little intelligence on our end to make sure that certain token values only apply to certain pages
[10:16am] bredgar: eliminating the "inside the app" attack
[10:17am] bredgar: these changes are more aimed at a 0.9 release as they will be a significant addition to the code
[10:17am] bredgar: I think
[10:17am] rcross: basically a combination of tokens based on session, page, and user
[10:17am] bredgar: (and that's once I convince myself that my idea isn't vulnerable to attack)
[10:17am] bredgar: yes
[10:18am] rcross: ok, sounds good to me - lets log an issue about it for 0.9 and plug the other holes we find for now
[10:18am] bredgar: cool
[10:18am] rcross: since we're getting closer to the end, i'll throw this out there for ProLoser|Work
[10:19am] ProLoser|Work: yes
[10:19am] 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
[10:20am] rcross: of course, we'll have to do it after the feature freeze so that we don't have to worry about breaking themes
[10:20am] 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
[10:20am] ProLoser|Work: rgr
[10:21am] ProLoser|Work: 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
[10:21am] 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
[10:22am] 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)
[10:22am] rcross: ProLoser|Work: now is the time to start making any changes to the themes
[10:22am] ProLoser|Work: rcross:changing markup for css only is what i refer to: removal of images and perhaps employment of standardized class/id names?
[10:22am] rcross: use the core default theme to reflect those changes in the css
[10:23am] ProLoser|Work: rcross: were you the individal (ryan?) who was working on conversion to jquery?
[10:23am] bredgar: that's rmmcue
[10:23am] rcross: ProLoser|Work: no, that is rmmcue (we're both ryan)
[10:24am] rhoward: rmccue.
[10:24am] rhoward: Err.
[10:24am] bredgar: sorry, rmccue
[10:24am] 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?
[10:24am] rcross: sure
[10:25am] ProLoser|Work: i'm assuming i'll have to bring up other dom changes seperate for id changes and possible structure
[10:25am] ProLoser|Work: for discussion first
[10:26am] 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
[10:26am] rcross: and have reasons why
[10:26am] ProLoser|Work: rgr
[10:26am] ProLoser|Work: some are probably more patch-related but overall i hope it helps themers in th eend
[10:27am] rcross: Timothee: i think you brought up the issue of patch review/testing last time. Did you want to go over that quickly today?
[10:27am] Timothee: well...
[10:28am] Timothee: I mentioned that because we need to make a bigger effort to make sure patches are reviewed and tested
[10:28am] Timothee: I'm not sure what the solution is though
[10:29am] Timothee: one thing could be to invite people who post patches to mention the main points to test (kind of white box testing)
[10:29am] rcross: ProLoser|Work: maybe you can help here since you're more of a newbie - what would help you to review/test patches?
[10:30am] rcross: i think that should generally be done anyways tim
[10:30am] ProLoser|Work: 1 sec
[10:30am] rcross: but good point
[10:30am] bredgar: hey, i gotta run fellas
[10:30am] rcross: ok, same time next week?
[10:30am] ProLoser|Work: uh
[10:30am] Timothee: see you!
[10:30am] bredgar: i'll catch up with you all later on the mailing list and issue queue
[10:30am] bredgar: yep, same time next week
[10:30am] bredgar: take care!
[10:30am] rcross: bye brett
[10:30am] ProLoser|Work: uh... if the patches were small changes or easy to employ
[10:31am] bredgar left the chat room.
[10:31am] 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
[10:32am] rcross: ok
[10:32am] 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
[10:32am] 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
[10:32am] ProLoser|Work: i think if you guys let the layer be specified it would help GREATLY, like a checkbox to the layers affected
[10:33am] ProLoser|Work: and # of lines too might give an /idea/ in how much work it takes to review
[10:33am] ProLoser|Work: does that make sense or help at all?
[10:33am] 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?
[10:34am] 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
[10:34am] 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)
[10:35am] rcross: thats ok - i asked because you were new
[10:35am] 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
[10:36am] rcross: Timothee: like this review
[10:36am] 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
[10:36am] rcross: err.. http://projectpier.org/patch/review
[10:38am] ProLoser|Work: how best can i get ahold of the themer/ryan?
[10:40am] rcross: you can use his contact page on the website
[10:42am] Timothee: yes, but maybe adding some technical details... something like "check out the SVN trunk, apply the patch..." blablabla
[10:42am] Timothee: but that review page is good too
[10:42am] rcross: Timothee: ok, would you be willing to write up something - even if its just a stub for people to contribute to
[10:43am] Timothee: I would be...
[10:43am] Timothee: please bug me if I don't though
[10:43am] rcross: ok
[10:43am] Timothee: I still owe you a doc about Eclipse from last year :)
[10:43am] rcross: i know :)
[10:43am] Timothee: (I don't even use Eclipse anymore)
[10:43am] Timothee: I did start the doc!
[10:43am] rcross: would emailing out the list of key issues be easier for you?
[10:43am] Timothee: I think it's almost finished...
[10:44am] Timothee: not necessarily.
[10:45am] ProLoser|Work: oh ya one last thing
[10:45am] ProLoser|Work: pssh nvm
[10:45am] rcross: ?
[10:46am] ProLoser|Work: i was gonna ask do you guys let people override your js files but i think it's a silly question
[10:46am] rcross: yea, i don't think so
[10:47am] ProLoser|Work: wait what?
[10:47am] ProLoser|Work: you don't really support people putting in their own js?
[10:49am] rcross: well, i don't think there is scope for it in the current plugin system so any custom js would be seperate
[10:49am] rcross: plus, i don't think you can override js in the same way as css
[10:50am] ProLoser|Work: well that's sorta what i want to implement i /think/
[10:50am] ProLoser|Work: 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
[10:50am] rcross: well, start with the small things, then we can move onto that
[10:50am] ProLoser|Work: rgr, honestly it's kind of an irrelevent queestion
[10:50am] ProLoser|Work: but i have one for you guys: http://projectpier.org/node/1216 saw this post
[10:51am] ProLoser|Work: 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
[10:52am] ProLoser|Work: grr, i think i just need to sit down with a themer and ryan to see how to go about this
[10:54am] 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
[10:54am] ProLoser|Work: well one thing i thought to help you guys
[10:55am] ProLoser|Work: oh ya nvm
[10:55am] ProLoser|Work: back to work
[10:55am] rcross: yep, thanks for a good meeting gusy
[10:55am] rcross: guys
[10:55am] rcross: keep up the good work and we'll meet again next week