Conversation with #fluxbb

Conversation with #fluxbb on Sun 16 Jan 2011 13:34:11 GMT:
(13:34:11) The topic for #fluxbb is: FluxBB - light and modern PHP forum software | http://fluxbb.org | Current stable release: v1.4.2
(13:34:11) mode (+o Reines) by ChanServ
(15:39:08) ZaherDirkey1 [~ZADI@178.253.100.87] entered the room.
(15:39:09) ZaherDirkey left the room (quit: Disconnected by services).
(15:39:09) ZaherDirkey1 is now known as ZaherDirkey
(16:55:46) ZaherDirkey left the room (quit: Read error: Connection reset by peer).
(17:01:22) InsertNameHere [97cce5f3@gateway/web/freenode/ip.151.204.229.243] entered the room.
(17:19:04) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects.

(20:04:07) The topic for #fluxbb is: FluxBB - light and modern PHP forum software | http://fluxbb.org | Current stable release: v1.4.2
(20:04:07) mode (+o Reines) by ChanServ
(20:04:50) richardk [c3f3a34a@gateway/web/freenode/ip.195.243.163.74] entered the room.
(20:25:15) Smartys [irc@96.232.26.212] entered the room.
(20:37:06) Franois [52e5ce97@gateway/web/freenode/ip.82.229.206.151] entered the room.
(20:38:48) Franois_ [52e5ce97@gateway/web/freenode/ip.82.229.206.151] entered the room.
(20:41:48) Franois left the room (quit: Ping timeout: 265 seconds).
(20:42:06) Franois_ left the room (quit: Client Quit).
(20:47:36) FSX: Reines: You're good with Java, right?
(20:48:48) Reines: I guess?
(20:48:53) Reines: whats up?
(20:49:39) FSX: How do make Swing GUIs without killing myself?
(20:49:54) Smartys: You don't
(20:49:59) FSX: FOr some reason .setSize() does not work...
(20:50:03) Smartys: Or you use NetBeans
(20:50:23) Reines: I'd agree with Smartys there lol
(20:50:31) FSX: It's a school assignment and my teammate made a wonderful GUI...
(20:50:39) Smartys: What are you trying to setSize on?
(20:50:45) FSX: JTextArea
(20:50:48) Smartys: and has the GUI already been rendered at that point?
(20:50:55) FSX: No
(20:51:00) Smartys: OK, try using setMinimumSize
(20:51:23) Reines: which layout is it using?
(20:51:41) FSX: Gridlayout.
(20:51:44) Franois [52e5ce97@gateway/web/freenode/ip.82.229.206.151] entered the room.
(20:52:33) Reines: I don't think you can really use setSize with a GridLayout, since the blocks in the grid are all equal size
(20:52:46) FSX: Fuck.
(20:53:02) Reines: setMinimumSize might have some effect like Smartys suggested, though not sure
(20:53:11) FSX: Then Screw him. Fuck the bonus assignment.
(20:53:19) FSX: I'm not going to redo that crap.
(20:53:22) Reines: haha
(20:53:27) Reines: that's the spirit
(20:53:31) Smartys: Well, what's the problem? You need the JTextArea to be larger than a grid box?
(20:53:38) FSX: Yes
(20:53:42) Smartys: OK, then you're fucked
(20:53:50) Smartys: GridLayout is highly inflexible like that
(20:54:37) Smartys: GridBagLayout is flexible enough to do what you want, but it will probably burn you in other ways
(20:54:37) FSX: Stupid teachers. They even recommended the GridLayout.
(20:54:54) Smartys: Oh, it's an absolutely wonderful layout, provided you're aware of its limitations
(20:55:03) Smartys: All of them have their purposes
(20:55:14) FSX: Teacher did not tell of limitations.
(20:55:17) Smartys: and I say this as someone who has coded Swing layouts by hang for fairly complex applications
(20:55:22) Smartys: Well, that
(20:55:25) Smartys: is just silly then
(20:55:43) Smartys: "The GridLayout class is a layout manager that lays out a container's components in a rectangular grid. The container is divided into equal-sized rectangles, and one component is placed in each rectangle."
(20:55:52) Smartys: (from the JavaDocs)
(20:56:21) FSX: k
(20:56:31) FSX: I don't like Java. I hate Swing.
(20:56:50) FSX: I made 50% of the bonus assignment. Should be enough.
(20:57:51) FSX: Thanks for the help anyways. Othwise I would have tried endlessly to get stuff working.
(20:57:56) Reines: I really like Java, though despise GUIs, unless you use something like netbeans GUI builder
(20:58:08) Smartys: Same
(20:58:22) FSX: DOesn't Java have GTK or Qt support?
(20:58:41) Smartys: Not built-in
(20:58:47) FSX: I see
(20:58:50) Smartys: Google seems to turn up a number of projects
(20:59:21) FSX: Reines: So why do you like Java?
(21:00:33) Reines: Well it's so much nicer than say C/C++ since you get proper OOP support and memory management and a proper collection of libraries
(21:01:27) FSX: And why not Python, Ruby or something else? Becaue of speed?
(21:02:36) Reines: well they are interpreted languages so quite different
(21:02:51) FSX: I see
(21:02:57) Quy [46bb85d9@gateway/web/freenode/ip.70.187.133.217] entered the room.
(21:03:05) Reines: though to be fair it's also down to knowing java quite well and not python or ruby :P
(21:03:44) FSX: Python is sweet.
(21:03:47) lie2815 [~lie2815@brln-d9ba6652.pool.mediaWays.net] entered the room.
(21:03:47) mode (+o lie2815) by ChanServ
(21:03:55) lie2815: hi everybody
(21:04:00) Oldskool: evening all
(21:04:02) FSX: Helloes
(21:04:04) Reines: hey
(21:04:13) lie2815: looks like everybody's there - and i'm the last one ;)
(21:04:17) Oldskool: is this where the party's at? ;)
(21:04:32) lie2815: which would be fairly ironic given that i'm the one who arranged the meeting
(21:04:41) lie2815: quy, are you there?
(21:04:52) FSX: Important people arrive at the very last moment. ;)
(21:05:04) lie2815: :)
(21:05:19) Quy: yes
(21:06:05) lie2815: let's roll, then. i suppose we'll let reines lead, eh?
(21:06:15) Reines: does it help I've got a raging headache?
(21:06:55) Oldskool: probably not, might wanna grab some aspirin
(21:07:25) richardk left the room (quit: Ping timeout: 265 seconds).
(21:07:40) Reines: https://docs.google.com/document/d/1ooR0iUdQ3PXigeLv0MT6W0fIMAFsIiRT5rr6zF6YRck/edit?hl=en_GB&authkey=CJCYyqIO
(21:07:43) Reines: can people see that?
(21:07:59) FSX: I can
(21:08:12) Oldskool: yeah, it's accessible
(21:08:13) lie2815: yup
(21:08:24) Quy: yes
(21:08:39) Oldskool: just what the access level "Anyone with the link" would suggest :)
(21:09:14) lie2815: well, to me "google" always looks like "beta". so there's always reason to hope something won't work
(21:09:20) Reines: lol, good it's just a few notes I made, hopefully we can come up with some agreement about them and maybe order them in some sensible way
(21:10:45) lie2815: we've got jamie, frank, jan and quy, right? getting the names straight...
(21:10:48) Franois left the room (quit: Ping timeout: 265 seconds).
(21:10:59) Oldskool: that should be it, yep
(21:11:13) Reines: neal is here too, or at least was :P
(21:11:26) Smartys: yup ;)
(21:11:28) Franois [52e5ce97@gateway/web/freenode/ip.82.229.206.151] entered the room.
(21:11:43) Smartys: I'm just proof-reading some vulnerability writeups, but I'm here
(21:12:21) FSX: So were do we start? API?
(21:12:35) Oldskool: yeah, I think it's easiest to work from top to bottom
(21:12:45) Reines: The order there at the moment is pretty much random, though I guess the first point was to consider splitting fluxbb into a couple of layers - a so called API which would have private access to the database, providing a layer of abstraction
(21:13:39) FSX: Layers like topic management, forum management, user '', etc?
(21:13:46) lie2815: the idea is to have functions basically for all the CRUD stuff, like creating topics, editing posts etc., right?
(21:14:00) Reines: yeah along the lines of $fluxbb->fetch_user($id) and so on
(21:14:03) lie2815: jamie's first demo implementation adds it all to one class
(21:14:26) lie2815: https://github.com/reines/fluxbb/tree/fluxbb-2.0
(21:14:29) Smartys left the room (quit: Disconnected by services).
(21:14:37) Smartys [~irc@96.232.26.212] entered the room.
(21:14:46) richardk [c3f3a34a@gateway/web/freenode/ip.195.243.163.74] entered the room.
(21:14:48) Reines: yeah if it should stay in a single class or be split into something along the lines of $fluxbb->user->fetch($id) im not quite sure, but I guess that is more of an implementation detail
(21:15:25) lie2815: well, in general, it's a good idea. with the planned template system, we'd basically have a simple MVC pattern
(21:15:37) Oldskool: I think that last one is better, making the User an object of it's own with several functions that can be passed to it.
(21:15:52) Reines: though when it comes to extensions it should make life a bit easier since there would be a hook someone can hook into that will guarantee to affect all post creations, for example
(21:16:16) lie2815: reines: with which approach?
(21:16:39) Reines: either
(21:17:22) lie2815: we're not talking about something like active record, though, right?
(21:17:33) FSX: Oh btw, is someone also going to take notes of the decisions?
(21:17:45) lie2815: because with those, i always mess up how to do things like fetch_users vs. updating one user ;)
(21:17:52) lie2815: jamie wanted to
(21:17:59) FSX: Ok
(21:18:05) lie2815: that's why we have the google docs thing
(21:18:24) Reines: Shout if there is anything worth noting that I don't :P The google docs stuff should update live I think
(21:18:33) lie2815: and maybe it updates our data in their index faster ^^
(21:19:45) FSX: Is there more to discuss about the API?
(21:19:57) Oldskool: lie2815: if you'd see the user as an object and create a fetch function for it, I guess it would be easiest to pass an argument like 'single', 'group' or 'all' to it, like $flux->User->fetch('all'); or $flux->User->fetch('single', $user_id);
(21:20:40) Reines: the main issue with the API is which "components" should be "inside" the API and which "outside". for example...
(21:20:59) lie2815: ah, thanks // i've got one more question regarding the api: with private database abstraction, how do we make sure extensions can add entirely new database queries?
(21:21:11) lie2815: using __call()?
(21:21:57) Reines: I would imagine so. I didn't really think about it but letting the class be extended in some way or other shouldn't be hard
(21:22:01) Reines: __call might work nicely yeah
(21:22:50) Smartys: Mmm, can you explain what you mean by that?
(21:23:07) Reines: anyway the translation stuff I would probably argue should be outside the API - it's related to the frontend, not the backend database stuff. however that causes problems when returning error messages (for example, no subject provided, or all caps subject, etc). there is also the issue of sending emails, which must be handled inside the API, but how would we translate them if the language system is "outside" it?
(21:23:31) Reines: Smartys: me or lie2815?
(21:23:37) lie2815: smartys: if we've got a defined set of functions for database access in the api, and the database access object is a private member of that API class, how should we add more datatypes or other queries via extensions?
(21:24:17) Smartys: Well, the simplest way would be to not have the database be private. :P
(21:24:20) Smartys: (hear me out on this)
(21:24:33) Smartys: Ideally, you don't want anyone to access the database other than through the API
(21:24:38) lie2815: that's exactly why i asked :P
(21:24:39) FSX: Reines: Maybe you can work with error codes?
(21:24:57) Smartys: In practice though, people are going to write their own code to access database tables you don't control
(21:24:59) lie2815: i think the translation adapter should be available in the controller ("glue") and the templates only
(21:25:52) lie2815: you're right, though; the data access code should have nothing to do with translation stuff; that would be proper separation of concerns
(21:25:55) Smartys: So, why not encourage them to use the DB layer responsibly: use the API for cases where the API can be used, and write their own wrappers around the DB when it can't?
(21:26:17) lie2815: which could be done using __call().
(21:26:34) Smartys: How though? I'm not understanding how that works. That was my original question ;)
(21:27:03) lie2815: define __call() inside the api class and place a hook inside. extensions can now add their custom functions :)
(21:27:23) Smartys: And how can those functions access the DB?
(21:27:34) Smartys: Since the DB is a private instance field
(21:27:42) Smartys: Does the DB object get passed along?
(21:27:50) lie2815: oh, right. i forgot that hooks will work differently now#
(21:27:57) lie2815: that's another thing to discuss then
(21:28:03) lie2815: and definitely worth a note
(21:29:16) test_ [3e93c711@gateway/web/freenode/ip.62.147.199.17] entered the room.
(21:29:32) Smartys: Now, in terms of translation: has a decision been reached on what system is being used?
(21:30:15) FSX: Nit really I think.
(21:30:18) FSX: *Not
(21:30:26) Smartys: OK
(21:30:27) Reines: My vote would probably actually go for English keys now, but I don't really have string opinions either way
(21:30:34) Reines: strong*
(21:30:46) Smartys: Reines: Does that mean the plan is to use gettext?
(21:31:01) Oldskool: If we would like the community to translate (which would be preferred) I think we should keep it as easy as possible.
(21:31:03) lie2815: i'll need to send a mail to mpok. i spied on fluxbb.fr using google translate and they were quite upset over that suggestion for some reason ;)
(21:31:07) FSX: I would go for that too. I've been using it in Python and it works quite good.
(21:31:21) lie2815: fsx: gettext?
(21:31:21) Reines: Smartys: the data format, or the php implementation?
(21:31:26) FSX: lie2815: Yes
(21:31:29) Smartys: either or both
(21:32:28) Reines: php implementation, probably not since we'd need to emulate it anyway for people who don't have it enabled
(21:33:14) Smartys: Mmm, I'd check out how Wordpress uses it
(21:33:16) FSX: I also read something about gettext in PHP not being threadsafe. Not sure if that's still the case or that it even matters.
(21:33:27) Smartys: Why would that matter?
(21:33:31) lie2815: that can easily be cached, though, right? // never worked with gettext
(21:33:42) Reines: wordpress uses an emulated version of it
(21:34:00) test_ left the room (quit: Ping timeout: 265 seconds).
(21:34:10) FSX: Smartys: Dunno. Just thought it'd be usefull to day. ^^
(21:34:49) FSX: lie2815: I think the PHP extension caches it. I didn't see the PHP implementaion doing it when I tried it.
(21:35:30) lie2815: well, jamie wrote a nice caching lib; the question is just whether it should be possible
(21:35:35) Smartys: FSX: Actually, you're right about that being an issue. If you're supporting multiple languages on a single forum, you run into a race condition
(21:35:39) Reines: the gettext format seems a little odd to be - i know it's a standard, but it's rather weird to parse and not plain text
(21:35:52) lie2815: it allows for things like pluralization, too, right? my concerns went in that direction...
(21:36:14) Reines: it does, in theory
(21:36:21) Smartys: Reines: You're not the one parsing it though (except on the PHP end, where there are libraries that can be used)
(21:36:34) Smartys: The advantage of gettext is that it's a standard and that there are a ton of tools that support it
(21:36:47) Smartys: The disadvantage is our international community tends to dislike anything that involves change
(21:36:54) Smartys: At least change that they haven't proposed
(21:37:02) Smartys: (Please, bring on the hate-mail)
(21:37:04) Reines: definately, but the disadvantage is that you need 1 of said tools to edit it, you can't just do it in notepad etc
(21:37:13) lie2815: can we strip that out of the protocol? ^^
(21:37:17) simon: hello
(21:37:20) Reines: hi
(21:37:21) simon: lie2815, I'm sshine. :)
(21:37:25) lie2815: hi :)
(21:37:35) Smartys: Reines: Yes, but they exist and they're good tools.
(21:37:49) lie2815: and i'm not writing a translation center for nothing. seriously...
(21:37:56) simon: question: has anyone tried to used fuzzing techniques on flux?
(21:37:59) Reines: lol
(21:38:10) Smartys: simon: Not that I'm aware of, why?
(21:38:32) Franois: could we write langage pack for extension with this translation center ?
(21:38:49) simon: Smartys, it'd be neat. PHP web forums are a hot target for attacks.
(21:39:02) lie2815: not in it's current state, no. that will be explained later, not tonight ;)
(21:39:04) Smartys: Yes, but what would you expect fuzzing to find?
(21:39:10) FSX: Reines: Ini format wouldn't be bad too I think.
(21:39:15) Smartys: The only area that might be worth testing in that way would be the parser
(21:39:52) lie2815: i'm wondering: if i really get the translation center done (which i will), are there any other reasons to use gettext? because if not... :P
(21:40:03) Smartys: Reasons other than?
(21:40:27) lie2815: standard and lots of tools available?
(21:40:41) simon: lie2815, gettext is neat because you can systematically extrapolate strings and put them into a gettext editor. makes translation much easier for mortals.
(21:41:03) simon: (that's the reason I convince myself by, anyways.)
(21:41:17) Smartys: It's a good reason ;)
(21:41:25) lie2815: extrapolate? like how
(21:41:29) Reines: well I'm still strongly for using some format other than PHP, so unless something has a good argument for keeping it in PHP files I'd say really the question is do we want to use gettext format (being a standard and with many existing tools) or a more easily editable format such as XML or INI
(21:41:44) Smartys: http://en.wikipedia.org/wiki/GNU_gettext
(21:41:54) Smartys: xgettext command line tool
(21:41:56) lie2815: an easy format fits the fluxbb style of things
(21:42:23) Reines: does xgettext work with PHP?
(21:42:28) Reines: or is it designed just for C?
(21:42:41) FSX: lie2815: If you say that I would go for a text-based format.
(21:42:53) lie2815: and if we cache things in php format anyway, i really can't understand why we shouldn't store it in php files right away (save for possible security issues, which don't really go away with caching either)
(21:43:05) Smartys: Reines: There's no reason it wouldn't work in PHP, provided we use the _ function for calling gettext
(21:43:16) simon: lie2815, I don't think caching is a winning argument, either.
(21:44:02) lie2815: why add the extra layer of "complexity", though?
(21:44:03) simon: lie2815, xgettext assumes for a given syntax that the function called _ has a single argument that is the key in a dictionary.
(21:44:15) simon: lie2815, because of automation.
(21:44:58) lie2815: it's kinda like using an extra template layer (smarty) instead of PHP, to which somebody (smartys) could post a link :P
(21:45:07) Smartys: ;)
(21:45:08) Reines: lie2815: there is the security argument - which would go away using a "proper" format. additionally there is simply the argument of using the right tool for the job. php isn't the right tool for storing translations
(21:45:13) Oldskool: Well, technically gettext might be a good choice, but I think it's also important to keep community translations in mind. It should be easy for anyone (also non-technical) to translate Flux into their native language.
(21:45:23) Smartys: http://www.poedit.net/ | If you want an example of a translation tool
(21:45:45) lie2815: you guys will make me hate the words "translation center"
(21:45:54) lie2815: maybe i should have posted my plans before this meeting ;)
(21:45:57) simon: lie2815, again, the argument that convinces me is Poedit, which is a gettext editor I can give to people, and they can help me translate and add notes.
(21:46:19) simon: lie2815, I'm sorry, I didn't know this is a meeting. let me know if I should mind my own business. ;)
(21:46:39) lie2815: simon: lol, absolutely no problem. contribution like that is welcome.
(21:47:06) simon: lie2815, personally I think Apache's automatic caching of gettext is a little annoying, but probably useful if one can wield it properly.
(21:47:16) lie2815: though i must say i've been holding this up far too much; it's not _that_ important to me and we should really move on to more important things
(21:47:53) Reines: to be honest that's probably a good idea - we shouldn't make any final decision without first hearing why fluxbb.fr are so against english keys anyway
(21:48:23) Reines: even though I get the feeling it might simply be because they feel it makes them a second class citizen
(21:48:42) Smartys: It's because they don't know how standard translation tools work
(21:49:05) Smartys: They're used to what they have right now, which is a text editor and a copy of the English language file
(21:49:05) simon: Reines, unless they propose Esperanto, English is probably the lesser evil.
(21:49:10) lie2815: regarding that: i think the typo argument was the weakest one in that discussion ;)
(21:49:16) Smartys: Indeed
(21:49:40) Reines: the other issue related to language stuff though is where it fits into the API idea
(21:50:36) FSX: If the language files contain no markup then I think it should be no problem if it's used in the API.
(21:50:36) lie2815: i think we need to find a way to clearly separate it from the api
(21:50:43) Smartys: Why can't language be its own separate API, along with a function _
(21:50:46) lie2815: be it through special error return codes or exceptions
(21:50:56) Smartys: Have it set up by default to be English
(21:51:01) Reines: I would suggest outside the API since the API (as I imagine it at least) wouldn't be tied to a specific user. however that causes issues when attempting to return errors from a function, or send emails. FSX you suggested error codes, though that has issues if you want to return an error such as "the username X is already taken" - we can't just strip the X out otherwise we get less useful error messages.
(21:51:21) lie2815: smartys: i think that's not the problem; the question is whether the forum API (fetch_topics etc) can access it
(21:51:30) Smartys: I would say yes, by calling _
(21:51:36) Smartys: What's the problem with that?
(21:51:58) lie2815: separation of concerns???
(21:52:17) Smartys: I didn't say the API should be loading language files on its own
(21:52:33) lie2815: in a way sending emails is controller code...
(21:52:40) lie2815: me neither
(21:52:51) Smartys: So what is your concern about separation of concerns?
(21:52:54) Smartys: ;)
(21:52:59) lie2815: :P
(21:53:45) Reines: that actually sounds reasonable
(21:54:05) Smartys: I'm in the process of writing up a little example
(21:54:12) Smartys: Give me a moment :)
(21:55:08) Reines: how about email templates, since they are separate from translated strings?
(21:55:30) lie2815: smartys: well, in theory (granted, this would not be possible with the suggested implementation, i think) the data component should be usable without the rest of the code (frontend stuff), and translation things (which are essentially frontend matters) shouldn't matter to the data access code
(21:55:32) Reines: or would it be worth forgetting the translated templates and actually just using translated strings for them?
(21:55:44) lie2815: reines: yeah, mail templates are causing me headaches, too
(21:56:08) Smartys: lie2815: Fine, then your code throws exceptions with messages in English.
(21:56:18) Smartys: and each Exception is defined separately
(21:56:31) lie2815: ok, i vote your approach then ;)
(21:56:35) Smartys: and some higher level code can change out the exception with some language stuff if you want
(21:56:36) Smartys: :P
(21:57:14) Smartys: There is separation of concerns, but at some point you have to tie your concerns together
(21:57:19) Reines: even if the API was to use _ and be used separately, presumably it would just fall back since the translation doesn't exist and work fine in English? The only problem would be if it was used separately AND gettext extension didn't exist and wasn't emulated?
(21:57:59) Reines: In which case it would be easy to either say the API requires gettext/an emulated gettext
(21:58:04) Smartys: Right, but you wouldn't want someone to use the API code without the related language enulation code anyway.
(21:58:09) Smartys: emulation*
(21:58:12) Smartys: Exactly
(21:59:05) Reines: does anyone know why we currently use email templates, instead of simply normal translated strings in emails?
(21:59:17) Reines: they seem a pain in the ass for no real benefit
(21:59:22) lie2815: maybe i'm just throwing buzzwords out there without knowing what i'm saying. but with passing the translation adapter to the api, we'd have proper dependency injection, eh?
(22:00:24) FSX: Hmm, if you're using _() do you really need to pass an instance around?
(22:00:31) Smartys: No, you don't
(22:00:41) lie2815: there we go again. you're right
(22:00:49) Smartys: :P
(22:00:51) Smartys: that's OK :)
(22:01:04) lie2815: of course it is
(22:01:26) FSX: Just popped in my mind. If we're going to use English as a fallback language.
(22:01:48) FSX: Caching could fill the missing entries in language files.
(22:01:55) FSX: Then you don't havr to check on runtime.
(22:02:03) Smartys: Hmm?
(22:02:29) Smartys: Could you explain that a little more?
(22:02:35) FSX: Yes
(22:02:39) lie2815: can we move on to email templates and then continue? i have to go to the airport tomorrow 4 am :P
(22:02:54) Reines: rofl
(22:02:55) Quy: For ban, duplicate, new registration mails, we use translated strings. To be consistent, not use the email templates.
(22:03:15) Reines: FSX: Only if you have a list of all possible keys somewhere to check which are missing from the language pack you're using
(22:03:21) lie2815: fsx: i suggested something similar to this in that (in)famous thread. but then, this required knowledge of my secret translation center again ;)
(22:03:48) FSX: Reines: If you use english keys then it won't be a problem.
(22:03:59) lie2815: reines: can't you just take the english ones, merge the translated ones and off you go?
(22:04:14) Reines: where do you get the english ones from if they are just dotted around in _() calls?
(22:04:22) Reines: there wouldn't be an English language pack
(22:04:35) Smartys: xgettext
(22:04:38) Smartys: That's what it's for
(22:04:43) lie2815: uh. oh. i thought gettext would always give you a default one?
(22:04:46) Smartys: That's how you build a language file to begin with
(22:05:08) FSX: lie2815: Yes, but I was talking about a PHP implementation.
(22:05:11) Smartys: You write the code and call xgettext, which spits out a language file ready to be filled in
(22:05:13) simon: lie2815, it defaults to they keyname, which would be an English sentence.
(22:05:31) lie2815: exactly
(22:05:40) lie2815: and there goes our problem, no?
(22:05:44) Reines: Smartys: yeah but that would require shipping a file with the output from that in it specifically for this, right?
(22:05:45) Smartys: Correct
(22:06:02) Smartys: When you say "shipping a file"
(22:06:20) Smartys: Do you mean "in order to generate an [SOME LANGUAGE] language pack, you need to use that file as a base"
(22:06:20) Smartys: ?
(22:07:13) Reines: Well from FSX suggestion what I understood was he was suggesting when a language pack is to be cached we would automatically check it wasn't missing any keys, and if it was fill them in in the cached copy.
(22:07:32) FSX: Reines: Yes.
(22:07:50) FSX: YOu can use array_merge for that.
(22:08:03) Smartys: Why are we worrying about caching the language file entries when basic aspects of the design haven't been decided yet?
(22:08:13) lie2815: thank you!
(22:08:18) FSX: It was just an idea :P
(22:08:30) Smartys: And it's a good one, but I think it would be more productive to discuss it later on
(22:08:37) Reines: well lets move on - database layer?
(22:08:43) lie2815: so, to sum this up: gettext seems like a fine idea; we need to figure out caching and fallback support
(22:09:03) Smartys: Yes to both (although I think fallback support is inherently built in)
(22:09:15) Smartys: Both meaning Reines and lie2815
(22:09:16) Smartys: ;)
(22:09:17) lie2815: by chance, jamie open-sourced a database abstraction layer today :P
(22:09:25) Smartys: By chance! :P
(22:09:30) lie2815: duh
(22:09:40) Reines: as far as I see it there are 4 requirements to the database layer: queries have to be extensible, for extensions. it needs SQL abstraction, driver abstraction, and automatic parameter sanitization.
(22:10:00) lie2815: a huge YES for the fourth point!
(22:10:02) Smartys: Oh look, and it supports all of the dblayers we want to support!
(22:10:03) Reines: lie2815 it isn't finished/or working properly :P
(22:10:04) Smartys: How wonderful
(22:10:10) lie2815: rofl
(22:10:12) Smartys: lol :P
(22:10:53) Smartys: mysqli_real_escape_string makes me sad :(
(22:11:14) lie2815: uhm... now i am the one dragging along, but what you said about email templates essentially means that you want to build long strings (with linebreaks, ugh) on-the-fly, consisting of multiple translateable strings?
(22:11:20) FSX: Why? It's such a short name. I always use it!
(22:11:27) Smartys: :P
(22:11:28) lie2815: sad to see it go
(22:11:32) Reines: I don't think we really need a huge amount of discussion about the db layer at the moment, the SQL and driver abstraction should be fairly straight forward, though it's maybe worth considering if PDO is a sensible option or not? i.e. how bad is its performance
(22:12:04) lie2815: i like how you did both adapter _and_ dialect abstraction, though. thumbs up!
(22:12:32) FSX: Reines: I don't know. You still have to deal with the different dialects.
(22:12:46) lie2815: (i think our protocol is just getting longer because we add more questions :P )
(22:12:59) Reines: sure but it would solve the driver part. granted that isn't hard, but PDO is designed to do just that
(22:13:20) lie2815: is it known to be very slow?
(22:13:23) Oldskool: PDO is a pretty good solution.
(22:13:29) Smartys: http://jonathanrobson.me/2010/06/mysqli-vs-pdo-benchmarks
(22:13:39) Smartys: "For inserts, there was no significant difference between MySQLi and PDO (prepared statements or not). For selects, MySQLi was about 2.5% faster for non-prepared statements and about 6.7% faster for prepared statements.
(22:13:42) Oldskool: not really, but a few benches should quickly tell if there's any difference in latency
(22:13:48) Quy: Look at the templates, they are short text and it shouldn'tt be too bad to be translated strings.
(22:14:22) Quy: I see them in templates for ease of formatting, but how often is this done?
(22:14:31) Smartys: Quy: The problem is two-fold.
(22:14:44) lie2815: reines: are you still planning to cache the generated queries?
(22:15:00) Smartys: 1. They're long strings. They have to be treated as a single string, because otherwise there will be translation problems and people will get mad.
(22:15:36) Smartys: 2. They SHOULD be editable by the administrators. An admin should really be personalizing the email, especially so that it doesn't look like bulk mail.
(22:15:53) Smartys: If we throw out #2, there's no problem with just sticking them in the language files.
(22:15:54) Reines: well that would be part of the query builder, though I imagine so - as long as there is a way to do it that still allows extensions to alter the queries without the wrong (cached) SQL being returned (in other words they would also need to alter the cache key I guess)
(22:16:46) lie2815: so we'd need to generate some hash or other id value from the arrays passed to the query builder, right? and then cache it there?
(22:16:56) Smartys: Shouldn't changing the query invalidate the key?
(22:17:03) lie2815: i really thought the cache code around each query was ugly ^^
(22:17:52) Reines: well it probably makes sense to look at where, if anywhere, the performance hit is. there's no point generating the query object then generating a key from that, if that has as bad performance as just generating the SQL from it instead of the key
(22:18:05) lie2815: exactly
(22:18:40) lie2815: though doing md5(serialize()) should not be as bad as all that array mumbo-jumbo
(22:19:11) Reines: well except making a SELECT query is basically return 'SELECT '.implode(',', $fields).' FROM '.$table
(22:19:54) lie2815: well, with which type of queries will we have the biggest performance hit because of abstraction?
(22:20:07) Reines: need to do some benchmarking I guess :p
(22:21:36) Reines: When it comes to automatic parameter sanitization, I see 2 options really - prepared statements or a custom vsprintf which replaces, for example, %s with $db->ecsape($val). prepared statements seem the "proper" way to go, but are only supported by some database engines, and do have a performance hit. is a custom vsprintf sufficient?
(22:22:07) Smartys: Which systems don't support prepared statements?
(22:22:19) lie2815: can't we do prepared statements when supported, and vsprintf() when needed (the latter shouldn't be all that fast either)?
(22:22:34) Reines: not sure, I just noticed it mentioned on the PDO page that PDO emulates them for systems that don't support them
(22:22:44) Smartys: All of the systems we use have them
(22:22:54) lie2815: question: can we kick sqlite2?
(22:22:55) Smartys: SQLite (well, at least 3 does), Postgres, MySQL
(22:22:58) Smartys: YES YES YES YES YES
(22:23:02) Smartys: KILL IT WITH FIRE
(22:23:04) lie2815: good good good
(22:23:05) FSX: lol
(22:23:07) Smartys: Nuke it from orbit, just to be sure
(22:23:09) lie2815: good
(22:23:14) Reines: lol, I don't see why not since it's easy to update a DB to SQLite3
(22:23:20) FSX: Smartys: You don't like it?
(22:23:28) lie2815: lol, i think they have a problem
(22:23:30) Reines: FSX: what gave you that idea?
(22:23:34) lie2815: smartys and sqlite2, they do
(22:23:41) lie2815: rofl
(22:23:51) Smartys: 2004 July 22 (2.8.15)
(22:23:58) Smartys: That was the last SQLite2 release
(22:24:07) Smartys: wait
(22:24:08) Smartys: maybe not
(22:24:19) Smartys: 2005 December 19 (2.8.17)
(22:24:20) lie2815: archaeology at it's best
(22:24:22) Smartys: OK
(22:24:29) lie2815: much better :P
(22:24:36) Oldskool: lol
(22:24:40) Smartys: And that was only because of a bug that caused data integrity issues
(22:24:44) Oldskool: think it's safe to say sqlite2 is OUT!
(22:24:50) Smartys: SQLite2 should be dead and buried, just like PHP 4
(22:24:51) antiyou [~antiyou@68-117-101-81.dhcp.eucl.wi.charter.com] entered the room.
(22:24:57) Oldskool: agreed
(22:25:23) lie2815: yeah, i think we already agreed on the php5 thing. unless there are objections? :P
(22:25:27) Oldskool: anything that's EOL should pretty much be considered dead (or at best a few months after that to grant ppl to upgrade)
(22:25:38) FSX: lie2815: We should use Python!
(22:26:01) FSX: Oldskool: I think PHP 5.2 is also EOL now.
(22:26:07) lie2815: fsx: somebody is going to wait for you. behind some dark street corner
(22:26:08) Reines: so Smartys you're suggestion would be prepared statements, even with a slight performance hit?
(22:26:19) Reines: your*
(22:26:23) Smartys: Yes. AppSecJesus will thank you for it.
(22:26:51) lie2815: oh, excellent point. we can probably safely jump to 5.1 or even 5.2? dunno about their adoption.
(22:27:03) Smartys: Also, SecurityHulk will smash you if you don't
(22:27:10) Reines: lol
(22:27:11) Smartys: (I've been enjoying my time on Twitter recently)
(22:27:27) lie2815: obviously
(22:27:29) FSX: Smartys: Is there any difference between prepared statements and the escape fucntions?
(22:27:34) Smartys: YES YES YES YES YES
(22:27:36) Smartys: :P
(22:27:45) Oldskool: FSX: yeah it is, and it wouldn't be bad to focus on 5.3 either.
(22:27:55) Smartys: Let me try and come up with a good analogy
(22:28:00) Reines: With prepared statements the SQL and parameters are actually send to the database engine separately, making it impossible for SQL injection
(22:28:02) FSX: Smartys: Mkay
(22:28:20) lie2815: twitter turns the best guys into exhibitionists (sorry, off-topic)
(22:28:39) Smartys: An escape function is like holding a loaded gun to your head and trying to remember not to pull the trigger
(22:28:41) lie2815: reines: are you saying there could, theoretically, possibly, be bugs in the escape functions that could allow this to happen?
(22:28:45) FSX: lie2815: Every social network does.
(22:28:51) Smartys: A prepared statement is like throwing the gun away
(22:28:56) Smartys: lie2815: No
(22:29:01) Smartys: But a stupid developer can do it
(22:29:31) Smartys: If no string concatenation is happening and you use prepared statements, nothing can go wrong
(22:29:40) FSX: I see.
(22:30:00) simon: huh?
(22:30:18) Reines: Should we move on from databases?
(22:30:27) FSX: I've used them a while ago and if requires extra code. WHich is a bit annoying.
(22:30:37) FSX: Sure\
(22:30:37) simon: oh, there's a PHP API for prepared statements. neat.
(22:30:44) Smartys: You as the developer don't have to handle it
(22:30:52) Smartys: The database layer abstracts that out somewhat
(22:31:04) lie2815: smartys: don't worry, i was talking about emulating prepared statements using escape functions
(22:31:07) Smartys: But avoiding string concatenation is a Good Thing (TM)
(22:31:35) FSX: Why does everyone always day "Good Thing (TM)" -_-
(22:31:41) Smartys: I know, but how would your system handles doubles? and dates? and other various fun data types
(22:32:06) Smartys: FSX: I don't quite know
(22:32:16) Smartys: I mean, I know why the (TM) stuff
(22:32:22) Reines: I don't really have any thoughts on the template engine - I was hoping Paul or someone would have something good, otherwise I was gonna worry about it later - anyone got ideas or should we skip it? lol
(22:32:28) Smartys: it's a joke based on the capitalization, because it looks like something you trademark
(22:32:47) FSX: Reines: Actually. I used Twig for work and it works quite nice.
(22:33:02) FSX: Smartys: Oh ok.
(22:33:08) lie2815: i think that will really be a fairly straight-forward simple template engine
(22:33:21) lie2815: php, of course. or smartys is going to come along and, well, ...
(22:33:32) lie2815: let's just say you don't want that
(22:34:01) lie2815: and paul kept saying he already has one for his version of 1.4. he'll just need to show us at some point :P
(22:34:06) FSX: Templates can be cached too so there's no reason to use PHP.
(22:34:23) Reines: i noticed he has part of it on github lie2815, but not anything finished/working by the look of it
(22:34:26) Smartys: what am I going to say? ;)
(22:34:37) lie2815: that is kinda what i said earlier; but totally in the wrong direction
(22:35:25) lie2815: oh, right, i forgot about that, jamie
(22:36:19) Reines: for the parser I understand ridgerunner has an almost completed rewrite which is much cleaner/more flexible than our current one, so it's probably an easy drop in for the bbcode parser. I'd quite like to design it modularly though so people could drop in a textile parser or whatever if they wanted to
(22:37:03) lie2815: reines: i think he didn't upload the template class yet, though
(22:37:17) Reines: yeah seems not
(22:37:29) lie2815: uhm, may i suggest a second meeting soon-ish? i REALLY should go soon
(22:37:40) FSX: Ok
(22:37:43) lie2815: but maybe we could talk about the plan for our first milestone (alpha1 or whatever)
(22:37:49) lie2815: plus, this was fun :)
(22:38:02) Oldskool: yeah, same here. nearing midnight and gotta get up at 7am again, so should go hit the sack soon.
(22:38:06) Reines: sure, maybe it's a good idea to try have meetings regularly then we can keep things moving
(22:38:15) Oldskool: sounds good.
(22:38:20) Oldskool: keeps things 'alive'
(22:38:33) lie2815: uh, i like the sound of that
(22:38:35) FSX: Maybe every sunday evening?
(22:38:41) lie2815: cough
(22:38:45) lie2815: not every sunday
(22:39:04) FSX: Why not? I have nothing to do on sunday evening :P
(22:39:05) lie2815: i'm fine with this coming sunday, but after that maybe once a month
(22:39:13) Reines: well how often probably depends on how much we've got to discuss, but sunday evening might be a good timeslot
(22:39:27) Oldskool: sunday evening works for me most of the time.
(22:40:28) lie2815: our doodle says everybody's got time next week, too (http://doodle.com/vxtaq9yia8exkdqd)
(22:40:49) lie2815: maybe ridgerunner can then join in, too
(22:40:50) Reines: alright we can draw a line for tonight then. I'll post up a log of this and the notes tonight and some rough agenda for next week then
(22:41:06) lie2815: thanks, guys! this was great!
(22:41:12) FSX: :)
(22:41:34) Reines: have fun getting up at 4 btw :P
(22:41:50) FSX: Omg
(22:41:56) lie2815: why, thanks