| 03:37.42 | *** join/#phlyte wps (~wade@65.73.113.199) |
| 03:37.46 | *** mode/#phlyte [+o wps] by ChanServ |
| 03:55.16 | *** join/#phlyte jbot (ibot@apt.bot.TimRiker.active.supporter.pdpc) |
| 03:55.16 | *** topic/#phlyte is UPHPU Mtg tonight 7pm | Phlyte web framework | Next meeting: June 30 @ 7pm | sponsored by UPHPU | Utah PHP Users | uphpu.org |
| 13:58.13 | *** join/#phlyte drip (~scoobmast@67.108.238.129.ptr.us.xo.net) |
| 14:18.57 | *** join/#phlyte jm_ul|w (~vircuser@12.125.156.114) |
| 14:18.59 | *** topic/#phlyte by macnewbold -> Phlyte web framework | Next meeting: June 30 @ 7pm | sponsored by UPHPU | Utah PHP Users | uphpu.org |
| 14:20.09 | *** topic/#phlyte by macnewbold -> Phlyte web framework - Next meeting: June 30 @ 7pm - sponsored by #uphpu |
| 14:32.34 | *** join/#phlyte wps (~wade@207.108.169.214) |
| 14:32.37 | *** mode/#phlyte [+o wps] by ChanServ |
| 15:18.35 | *** join/#phlyte greygnome (~greygnome@69.2.248.18) |
| 15:28.04 | *** join/#phlyte bigdog_ut (~bigdog@166.70.34.182) |
| 15:36.24 | *** join/#phlyte mindjuju (~mindjuju@216.20.238.225) |
| 15:46.46 | *** join/#phlyte mindjuju (~mindjuju@216.20.238.225) |
| 16:16.43 | *** join/#phlyte jsmith (~jsmith@64.50.35.114.2O7.net) |
| 16:25.59 | *** part/#phlyte greygnome (~greygnome@69.2.248.18) |
| 16:46.16 | jsmith | Anybody want to bring me up to speed on what has been decided on phlyte so far? |
| 16:47.06 | mindjuju | the name, the spelling, the project leader |
| 16:48.04 | mindjuju | php 4 for framework with some mods using php 5 |
| 16:49.04 | mindjuju | oop is currently being discussed with I think the majority setteling for oop used in certain circumstance |
| 16:49.10 | mindjuju | though for more on the oop scope, i'd ask mac |
| 16:50.06 | jsmith | OK. |
| 16:50.14 | mindjuju | are you on the project mailing list? |
| 16:50.15 | jsmith | Have we picked a db-abstraction layer? |
| 16:50.17 | jsmith | Yes. |
| 16:50.33 | jsmith | Have we decided on coding guidelines? |
| 16:50.39 | jsmith | A list of modules we'd like to see? |
| 16:53.50 | macnewbold | jsmith: coding style will be discussed at the next meeting |
| 16:54.04 | macnewbold | the list of potential modules was discussed, and a list was sent to the mailing list |
| 16:54.11 | macnewbold | you can grab the archives to see them: |
| 16:54.15 | macnewbold | ~phlyte archives |
| 16:54.15 | jbot | from memory, phlyte archives is http://ibot.rikers.org/%23phlyte/ and http://uphpu.org/pipermail/phlyte/ |
| 16:54.28 | *** join/#phlyte fungus (~fungus@firebat.aros.net) |
| 16:54.31 | jsmith | OK, thanks. |
| 16:54.34 | macnewbold | np |
| 16:54.42 | jsmith | Meeting is on the 30th, right? |
| 16:54.49 | macnewbold | yep |
| 16:54.57 | macnewbold | we're still not sure which db abstraction we'll use |
| 16:55.03 | jsmith | Cool... maybe I can make it this time :-) |
| 16:55.48 | bigdog_ut | perhaps since it is a framework you can support more than one db abstract layer |
| 16:55.50 | macnewbold | we've kind of punted on mssql support, I think, so it may end up being our own 10-line layer that wraps mysql_* and pgsql_* |
| 16:56.09 | macnewbold | bigdog_ut: if we have one that works, what's the advantage of supporting more than one? |
| 16:56.25 | bigdog_ut | framework |
| 16:56.25 | macnewbold | wouldn't that be like a "database abstraction abstraction layer"? |
| 16:56.27 | bigdog_ut | allows users to pick their owner |
| 16:56.41 | bigdog_ut | no |
| 16:56.43 | jsmith | macnewbold: PLEASE DON'T WRITE YOUR OWN! |
| 16:56.43 | macnewbold | since we'd have to abstract whether we were using adodb or pear::db? |
| 16:56.58 | macnewbold | the only reason we've even considered it |
| 16:57.01 | macnewbold | is in simplicity |
| 16:57.02 | bigdog_ut | kinda...hence my deal with objects |
| 16:57.04 | jsmith | WHAT? |
| 16:57.17 | jsmith | There's nothing simple about writing a good abstraction layer. |
| 16:57.31 | macnewbold | we'd like to use an extremely simple abstraction layer |
| 16:57.36 | bigdog_ut | most db ab layers are in object form |
| 16:57.45 | bigdog_ut | so really u are moving those around |
| 16:57.49 | jsmith | A *good* abstraction layer isn't just another layer of indirection -- it *ABSTRACTS* away the differences between the databases. |
| 16:57.57 | bigdog_ut | then use dbx from php |
| 16:58.03 | macnewbold | i.e. one that pretty much wraps "portable" sql queries and calls the corresponding correct function |
| 16:58.21 | macnewbold | jsmith: some differences cannot easily be abstracted away, no? |
| 16:58.30 | jsmith | macnewbold: Not easily, which is *EXACTLY* my point. |
| 16:58.34 | macnewbold | right |
| 16:58.49 | jsmith | macnewbold: A database abstraction layer should do more than just provide a friendly interface to the underlying functions. |
| 16:59.06 | fungus | If we do write our own, it won't be a "good" db abstraction layer, just a usuable one. |
| 16:59.11 | bigdog_ut | it should provide additional features |
| 16:59.18 | jsmith | macnewbold: It should do things like "limit this query to the top 100 rows" by doing the appropriate thing with the underlying database |
| 16:59.22 | macnewbold | so either we (a) use a complex abstraction layer, and make more complex calls, or (b) use a simple one, make simple calls, and don't support as many databases |
| 16:59.28 | jsmith | macnewbold: Same thing with handling date/time values, etc. |
| 16:59.43 | jsmith | fungus: Amen! |
| 16:59.52 | macnewbold | we also really want to avoid a learning curve on our abstraction layer |
| 16:59.59 | macnewbold | which would be the advantage of barely having one |
| 17:00.01 | bigdog_ut | no actually...the simple way is to wrap the objects of different db ab layers |
| 17:00.08 | macnewbold | huh? |
| 17:00.38 | bigdog_ut | this is my big push with objects...this is one of the main reasons to use them |
| 17:00.39 | jsmith | Look, I've been around the block a few hundred times when it comes to db-abstraction layers, and there's nothing I hate worse than seeing someone use a homegrown layer that offers no advantages (other than maybe syntactical sugar) over calling the native db functions. |
| 17:00.44 | fungus | Now abstracting the abstraction layer is just plain silly |
| 17:00.48 | jsmith | fungus: Amen again! |
| 17:00.54 | macnewbold | amen too |
| 17:01.06 | macnewbold | jsmith: I agree mostly... |
| 17:01.08 | bigdog_ut | that is not what we are talking about |
| 17:01.28 | bigdog_ut | the question is why not support the ability to plugin different db ab layers |
| 17:01.35 | bigdog_ut | not abstracting them out |
| 17:01.40 | bigdog_ut | with our own stuff |
| 17:01.40 | fungus | As alternative modules? |
| 17:01.53 | macnewbold | for now we've decided that the databases we care most about are similar enough that writing portable queries almost completely covers our needs |
| 17:01.55 | jsmith | bigdog_ut: I'm fine supporting multiple ones, but when we write a module, how does it know which one to use? |
| 17:02.09 | macnewbold | the only other thing we'd need is the sugar to call the right backend function |
| 17:02.10 | bigdog_ut | configuration files |
| 17:02.19 | jsmith | macnewbold: Wrong answer -- there's no such thing as "portable" SQL queries. |
| 17:02.40 | bigdog_ut | exactly...but what we are saying is that the user can use different db ab layers |
| 17:02.42 | jsmith | bigdog_ut: So lets say for a second I write an authentication module. |
| 17:02.43 | bigdog_ut | that is the key |
| 17:02.45 | macnewbold | we had different opinion expressed on that in the last meeting |
| 17:03.06 | bigdog_ut | jsmith, go on |
| 17:03.10 | jsmith | bigdog_ut: What database functions does it call? Some generic ones that wrap the underlying db-abstraction layer? |
| 17:03.10 | macnewbold | bigdog_ut: are you talking about different layers as in adodb vs pear::Db, or different as in mysql/pgsql? |
| 17:03.29 | bigdog_ut | here is what i am talking about |
| 17:03.41 | bigdog_ut | you allow various type of db ab layers |
| 17:03.49 | bigdog_ut | adodb, pear::db, user defined |
| 17:04.02 | bigdog_ut | we create the ability to plugin what the user wants |
| 17:04.08 | bigdog_ut | we create the api that will allow that |
| 17:04.15 | bigdog_ut | many db ab layers use objects |
| 17:04.18 | bigdog_ut | very easy to do |
| 17:04.23 | fungus | That *is* abstraction of the db ab. |
| 17:04.35 | bigdog_ut | thus we ahve a framework |
| 17:04.37 | bigdog_ut | no you are not abing the layer |
| 17:04.44 | bigdog_ut | you are doing plugin of a layer |
| 17:05.00 | fungus | That creates unnecessary complexity. |
| 17:05.00 | bigdog_ut | we dont abstract anything |
| 17:05.01 | bigdog_ut | no complexity at all |
| 17:05.01 | bigdog_ut | where is it complex? |
| 17:05.15 | fungus | You have to abstract the layer you choose, if you want more than one, they are very different. |
| 17:05.36 | bigdog_ut | no that is the misconception...how you are you abstracting a layer |
| 17:05.46 | bigdog_ut | both pear and adodb use objects |
| 17:05.57 | bigdog_ut | you are facilitating the creation of their objects |
| 17:05.58 | bigdog_ut | that is all |
| 17:06.28 | fungus | Example: the core will have user authentication. We must then make different calls based on which db ab is used. |
| 17:06.39 | bigdog_ut | the core should have plugin user auth |
| 17:06.51 | bigdog_ut | too as well..this allows the core to function as a framework |
| 17:07.28 | bigdog_ut | authentication is just queries |
| 17:07.30 | macnewbold | bigdog_ut: no offense, but I think you have different ideas of what a "framework" is and isn't than the rest of us seem to have |
| 17:07.30 | bigdog_ut | the db layer that is chosen can handle the queries |
| 17:08.09 | fungus | But we still have to wrap (abstract) the db ab in different query/fetching functions. |
| 17:08.14 | bigdog_ut | yeah...this seems more like an app too me |
| 17:08.17 | macnewbold | bigdog_ut: creating a different object is fine, but do they support the exact same API? If not, then interchanging objects won't work, you'd have to further abstract it. |
| 17:08.44 | bigdog_ut | all support the core functionality |
| 17:09.18 | jsmith | bigdog_ut: But often in radically different ways -- do we really want a "lowest common factor" approach? |
| 17:09.23 | macnewbold | maybe if you'd actually show up at Phlyte meetings once in a while, bigdog_ut, you'd understand better what we are working towards... <wink,wink, nudge, nudge> ;) |
| 17:09.39 | jsmith | bigdog_ut: I'd lean more towards a giant battle of minds until we all agree on an abstraction layer we can agree on. |
| 17:09.41 | bigdog_ut | jsmith, if you dont you dont have a framework you have another app |
| 17:09.52 | macnewbold | bologna |
| 17:10.06 | macnewbold | a framework can make choices for you, and still be a framework |
| 17:10.22 | macnewbold | heck, we're still leaving them the most important choice: which db do I use? |
| 17:10.26 | bigdog_ut | exaclty...framework allows you to choose whick db layer to use |
| 17:10.27 | fungus | ok, then lets not call it a framework and call it a skeleton. |
| 17:10.28 | macnewbold | so what if we choose which abstraction |
| 17:10.33 | macnewbold | we implement our code with |
| 17:11.06 | macnewbold | my idea of framework is probably a lot like bigdog's idea of skeleton |
| 17:11.09 | fungus | ruby on rails is a framework. It forces you to use a db ab. a very good one I do say. |
| 17:11.17 | macnewbold | here here |
| 17:11.23 | macnewbold | or is it hear hear? |
| 17:13.23 | mindjuju | i personally don't think this can be solved over an IRC channel. I think we should step up to the plate and buy everybody with an opinion a set of gloves. last man standing gets it his way |
| 17:13.24 | mindjuju | i'll ref |
| 17:13.43 | bigdog_ut | ill win |
| 17:13.57 | fungus | Not unless you can catch me. |
| 17:14.11 | macnewbold | I stand a much better chance in IRC than in person, I think |
| 17:14.16 | jsmith | Now I've really gotta make sure I come to the next meeting. |
| 17:14.20 | macnewbold | hehe |
| 17:14.25 | macnewbold | bigdog_ut: you coming on the 30th? |
| 17:14.32 | fungus | My only defensive/offensive skill is running. |
| 17:14.53 | mindjuju | how is running an offensive tactic? |
| 17:14.59 | macnewbold | what, no nunchuk skillz? |
| 17:15.05 | bigdog_ut | macnewbold, not sure...i might just bow down and out |
| 17:15.10 | macnewbold | if you run at them really fast... :) |
| 17:15.19 | macnewbold | bigdog_ut: we don't want to push you out if you're interested, |
| 17:15.34 | macnewbold | but at the same time, we've got to come to agreements on some things or progress will be difficult |
| 17:15.42 | bigdog_ut | if it is more of a skeleton i would not be interested...framework yes |
| 17:15.46 | macnewbold | but we haven't yet had a chance to sit down in person and talk through this enough |
| 17:16.12 | macnewbold | what we're planning fits very well into the definitions of framework I've been able to find |
| 17:16.17 | bigdog_ut | oh...it not just this though...i have strong opinions on oop, php5, and the concept |
| 17:16.38 | bigdog_ut | if others are cool i dont want to impied the progress |
| 17:16.42 | macnewbold | but what you have in mind is different, and I'd like to understand it |
| 17:16.50 | bigdog_ut | consensus from the group is better |
| 17:17.03 | bigdog_ut | check out spring framework |
| 17:17.09 | bigdog_ut | that is what i am thinking |
| 17:18.42 | macnewbold | this one? http://www.springframework.org/ |
| 17:19.47 | bigdog_ut | y |
| 17:19.48 | fungus | I was thinking something similar to cake. |
| 17:23.04 | dataw0lf | what? boxing to solve this problem. |
| 17:23.07 | dataw0lf | good idea. |
| 17:23.11 | dataw0lf | let's do this. |
| 17:23.26 | bigdog_ut | i got boxing and kungfu skillz |
| 17:23.28 | mindjuju | yeah, i though you'd be fore it. the real question is, what type of boxing |
| 17:23.42 | mindjuju | s/fore/for |
| 17:24.08 | bigdog_ut | mike tyson style...ill bite your ear of... |
| 17:24.13 | macnewbold | http://www.theserverside.com/articles/article.tss?l=SpringFramework |
| 17:24.36 | macnewbold | quotes from spring's leader about their goals/mission: |
| 17:24.37 | mindjuju | you did hear that ole' mike tried to take a nip on some guy's chet |
| 17:24.44 | fungus | Yeah reading that now and realizing that spring is way to far from what we want. |
| 17:24.56 | macnewbold | It addresses important areas that many other popular frameworks don't. Spring focuses around providing a way to manage your business objects. Spring is both comprehensive and modular. Spring has a layered architecture, meaning that you can choose to use just about any part of it in isolation, yet its architecture is internally consistent. So you get maximum value from your learning curve. You might choose to use Spring only to simplify u |
| 17:25.55 | macnewbold | Some of that is what I want to do: give you a bunch of pieces you can either use, or not |
| 17:26.07 | macnewbold | with a very small, simple, but useful core, |
| 17:26.28 | macnewbold | so you can make your use of the framework as heavy or light as you like |
| 17:26.47 | macnewbold | all the optional pieces should be consistent and use each other as needed |
| 17:27.17 | macnewbold | in many ways, the way I'm thinking of this is a lot like Aspect Oriented Programming (AOP) |
| 17:27.31 | macnewbold | where you change aspects of the way it works, and everything else cooperates |
| 17:27.51 | macnewbold | i.e. maybe your cart/checkout system requires users to log in and have an account, or maybe it doesn't |
| 17:28.35 | macnewbold | maybe you have cms-like tools, and maybe you don't, and if you do ,that uses the same login/auth system |
| 17:28.40 | macnewbold | as you would for the ecomm stuff |
| 17:28.42 | macnewbold | etc. |
| 17:29.11 | fungus | small parts loosely coupled. |
| 17:29.21 | macnewbold | here's cake: http://sputnik.pl/cake/ |
| 17:29.31 | macnewbold | what I don't like about it is how rigid it is |
| 17:29.58 | fungus | err "Small peices loosely joined". |
| 17:30.02 | macnewbold | sure |
| 17:30.21 | macnewbold | I want to erase the rigid "my way or the highway" attitude |
| 17:30.35 | macnewbold | give the user useful stuff that will fit into the way they want to do things |
| 17:30.45 | fungus | But we do have to make specific decisions to make it less complicated. |
| 17:30.50 | macnewbold | yes |
| 17:30.55 | macnewbold | but we can still leave lots of choices |
| 17:31.09 | macnewbold | and good defaults, if the user wants to accept them |
| 17:32.26 | macnewbold | from the cake intro: "Rails does all the paperwork involved with connecting to the database, setting up the templating, linking code to URLs in a meaningful way, and so on. You write the application business logics and fire it up. Very fast, very efficient programming, saves a lot of unnecessary bother." |
| 17:33.13 | macnewbold | the main goal I have with the framework is eliminating a lot of the unnecessary, redundant/repetitive, boring stuff that we do almost the same all the time |
| 17:33.41 | macnewbold | and to have it be simple enough to customize it where you want to do it very differently |
| 17:39.06 | *** join/#phlyte jsmith (~jsmith@64.50.35.114.2O7.net) |
| 17:54.36 | macnewbold | it's been a long time since I've had an app crash x... what were you using? |
| 18:03.58 | jsmith | Firefox. |
| 18:04.55 | jsmith | I was running a stupid .cgi script that tried to append about 25,000 characters to the GET string |
| 18:04.55 | jsmith | After about the third time, X crashed. |
| 18:35.15 | fungus | I would call that a DOS security threat you found. |
| 19:03.35 | jsmith | Yup. |
| 20:45.57 | *** join/#phlyte fungus (~fungus@firebat.aros.net) |
| 22:13.45 | *** join/#phlyte wps (~wade@207.108.169.214) |
| 22:14.03 | *** mode/#phlyte [+o wps] by ChanServ |
| 22:57.59 | *** join/#phlyte bigdog_ut (~bigdog@166.70.34.182) |
| 23:12.54 | *** join/#phlyte bigdog_ut (~bigdog@166.70.34.182) |
| 23:13.24 | *** join/#phlyte phpguy (~bigdog@166.70.34.182) |
| 23:41.35 | *** join/#phlyte fungus_ (~fungus@firebat.aros.net) |
| 23:45.08 | *** join/#phlyte wps (~wade@65.73.113.199) |
| 23:45.11 | *** mode/#phlyte [+o wps] by ChanServ |
| 23:56.10 | *** join/#phlyte fungus_ (~fungus@firebat.aros.net) |