From geeklog at langfamily.ca Sun Aug 1 10:33:02 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Sun, 1 Aug 2004 10:33:02 -0400 Subject: [geeklog-devel] Is this rocking the boat? References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> Message-ID: <002301c477d4$7374e7f0$650a10ac@XPBL2> It does look interesting and like many new libraries or models, it may be able to improve code readability, reduce code size, and improve re-useability but I do wonder if 1) There are any SQL usage restrictions or more complex SQL queries that will not work. 2) Will you still be able to use another DB access method and direct mysql_ calls using PHP 3) Making GL2 too complex to understand for developers will effect it's support I have had reason on several occasions to need to access another mysql database when doing application integration. I just used the direct php mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x does not support this. We should consider this need in GL2 Blaine ----- Original Message ----- From: "Vincent Furia" To: Sent: Saturday, July 31, 2004 11:17 PM Subject: Re: [geeklog-devel] Is this rocking the boat? I haven't had enough time to read up on this extensively, but it looks promising. We just have to make sure that it fulfills all our needs completely and won't cause any problems down the road. Also, we have to be able to support it on the off chance that the current developers drop the project. My one worry is possible performance penalties. I think we should check how much overhead Propel requires. Most importantly: I want to see GL2 get moving really soon. So a decision on this has to happen soon. Can we get enough research done on this topic that we're not causing more delays? I'll spend some more time reading the Propel docs. If nothing else the idea sounds pretty interesting. -Vinny On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > Ok, I think I sent this link here, but the more I read what I see, the > more I like it. Please take some time to read about Propel: > > http://propel.phpdb.org > > And read the user guide: > > http://propel.phpdb.org/docs/user_guide/ > > The long and short of it is this. We could implement Data Acces Objects > that our code uses to interact with the database. DAO is a good idea no > matter what DB abstraction layer we use and regardless if we use a tool > like Propel. Essentially it hides the data access specifics from the > developers. Instead developers will call simple methods on the data > access objects and let the DAO layer do the grunt work. > > We could essentially use DAO to wrap the use of Propel for data acess. > > That said there are some pros and cons: > > Pros: > 1) Clean API, developers no longer have to write SQL except in really > rare instances. > 2) Object oriented...right in line with GL2 > 3) Database changes are easier, now developers don't have to find all > SQL effected by a database change. We simply change things at the > Propel level (wrapped by DAO), modify our HTML templates and we are off > to the race. > > Cons: > 1) It is conceptionally more complicated. Requires some ramp up. > 2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even > if you wanted to). > 3) It's in Beta. > > I think this tool could really save a ton of time. Please give this a > gander and try using it against a very simply table and let me know your > thoughts. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Sun Aug 1 10:42:38 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Sun, 1 Aug 2004 10:42:38 -0400 Subject: [geeklog-devel] GL2 event model References: <40FEE0CD.9000901@tonybibbs.com> <20040721220312.M50280@pigstye.net> <8319e2d604072118231fa09b79@mail.gmail.com> <410AB49B.6070609@tonybibbs.com> <8319e2d604073120117cdc5d86@mail.gmail.com> Message-ID: <002901c477d5$ca6a73d0$650a10ac@XPBL2> I like this idea of a priority field for the event model. As Vinny noted, a 2nd level of privilege for core functions is also needed. We have the issue now in GL1.3 where we scan the plugins to see if functions are present and it's in order of installation. So if 3 plugins have a centerblock, you have no way of changing the order. I don't know if thats a good example of usage for this field - I don't think it is so there may be another field used to control this. Do we need to have classes of plugins or modules as well. - Core - Service Providers (Messenging, Formatting) - Interface Related - Misc Just wondering if this classification would be useful. Blaine ----- Original Message ----- From: "Vincent Furia" To: Sent: Saturday, July 31, 2004 11:11 PM Subject: Re: [geeklog-devel] GL2 event model No problem with the addition that Tony made. I also agree that we should add a 'precedence' (what Tony call priority) field. I think this is as easy as changing one function in the class: public function registerListener($events, $plugin) --to-- public function registerListener($events, $plugin, $precedence = 100) And when the $listeners field is loaded, the array of events should be populate in order lower precedence to higher precedence. Where $precedence is an integer that we recommend goes from 0 - 255. The Geeklog core then could potentially use precedence values > 255 or < 0 if it needs to operate before or after all the other plugins. Really, I don't think it matters what numbers we use, so any suggestions that are more logical from a plugin developers standpoint would be great. -Vinny On Fri, 30 Jul 2004 15:50:35 -0500, Tony Bibbs wrote: > To fill in the blanks more I offer up the attached version. Only > difference is I show how the plugins are actually called. Also, we > might want to consider a 'priority' field for events that plugins listen > to. Using priorities would allow plugins to get called in some sort of > priorty fashion. I say that we come up with a standard set of > priorities that plugins can use. This make sense? > > --Tony > > > > Vincent Furia wrote: > > >Here is what I had envisioned when I penned the Plugin API > >documentation. It is a class that would be instantiated only once by > >GL2 core and available globally. I prefer the per event registration > >as it will reduce the calls the "PluginEventHanlder" will have to make > >to listening plugins. > > > >-Vinny > > > >class PluginEventHandler { > > > > /** > > * Array containing event keys and listener (arrays as) values > > * @access private > > * @var array > > */ > > private $listeners = array(); > > > > /** > > * PluginEventHandler Constructor > > * > > * @access public > > * > > */ > > function __construct() { > > // fetch registered listeners from database, populate $listeners > > } > > > > /** > > * Register a plugin to listen for an event > > * > > * @access public > > * @param mixed $event event(s) to listen for (string or array) > > * @param string $plugin plugin to be registered as listener > > * @return boolean true on success > > * > > */ > > function registerListener($event, $plugin) { > > // add the listener to the $listeners variable and the database > > } > > > > /** > > * Unregister a plugin from listening for an event > > * > > * @access public > > * @param mixed $event event(s) to unregister (string or array) > > * @param string $plugin plugin to be unregistered as listener > > * @return boolean true on success > > * > > */ > > function unregisterListener($event, $plugin) { > > // remove the listener for the specified events from $listeners > > // and the database. > > } > > > > /** > > * Get all the listeners for a specific event > > * > > * @access public > > * @param string $event event to get listeners of > > * @return array array of listeners to event $event > > * > > */ > > function getListeners($event) { > > // remove the listener for the specified events from $listeners > > // and the database. > > } > > > > /** > > * Notify all listeners that an event has occurred > > * > > * @access public > > * @param mixed $event event requiring notification > > * @param mixed $vars event specific variables > > * @param mixed $plugin NOTIFY_ALL, specific plugin, or array of plugins > > * @return mixed event specific return values (or array of) > > * > > */ > > function notify($event, $vars, $plugin = NOTIFY_ALL) { > > > > } > > > >} > > > > > > > >On Wed, 21 Jul 2004 22:10:55 +0000, Tom Willett wrote: > > > > > >>Let me get this straight. > >> > >>GL2 Core would make the MySubjectObserverClass > >> > >>$obs = new MySubjectObserverClass; > >> > >>then the plugin would register by somehow getting the reference to the > >>MySubjectOvserverClass and register itself as a listener > >> > >>$obs->addListner($MyPlugin); > >>or > >>$obs->addListener($MyPlugin, $events); > >>etc > >> > >>Then when a event happened GL2 Core or a plugin could notify the plugins > >> > >>$obs->notifyAll($event) > >> > >>Do I have this about right? > >> > >>-- > >>Tom Willett > >>tomw at pigstye.net > >> > >> > >> > >>---------- Original Message ----------- > >>From: Tony Bibbs > >>To: geeklog-devel at lists.geeklog.net > >>Sent: Wed, 21 Jul 2004 16:31:57 -0500 > >>Subject: [geeklog-devel] GL2 event model > >> > >> > >> > >>>The plugin API for GL2 that Vinny has drafted if surprisingly small > >>>because we are introducing an event based model. Essentially, the GL2 > >>>and all plugins have the option to register events that others can > >>>listen to. To implement this I recommend an observer/observable design > >>>pattern similar to the example below. A few things that need > >>>discussion. First, the example below allows listening only at the > >>>object level. The alternative is the force listening at the event level > >>>(in otherwords, addListener would take as a second arg an array of > >>>events the object listens to). Any preference? General questions?: > >>> > >>>class MySubjectObserverClass { > >>> private $listeners = array(); > >>> private $listernerNextID = 0; > >>> > >>> // Alternative names: register, subscribe... > >>> public function addListerner(&$obj) > >>> { > >>> $this->_listerners[] =& $obj; > >>> return $this->listernerNextID++; > >>> } > >>> > >>> // Alternative name: unregister, unsubscribe... > >>> public function removeListerner($id,'even't) > >>> { > >>> unset($this->listerners[$id]); > >>> } > >>> > >>> // Alternative name: broadcast... > >>> public function notifyAll($event) > >>> { > >>> foreach ($this->listerners as $id => $obj) > >>> { > >>> $this->listerners[$id]->notify($event, $this); > >>> } > >>> } > >>> > >>> // Alternative name: listen... > >>> function notify($event, &$obj) > >>> { > >>> switch (get_class($obj)) { > >>> case 'blah': > >>> ... > >>> } > >>> } > >>>} > >>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>------- End of Original Message ------- > >> > >> > >> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Sun Aug 1 10:47:06 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Sun, 1 Aug 2004 10:47:06 -0400 Subject: [geeklog-devel] 1.3.10 to do list References: <000a01c47734$e64fca10$650a10ac@XPBL2> <20040731210655.29477@smtp.haun-online.de> Message-ID: <003f01c477d6$6a3659b0$650a10ac@XPBL2> I will go ahead then an add the "Archive" type option in the TopicEditor but we will only allow 1 topic to be defined as the archive topic at this time. I also need to extract out the language that I left in the template files ;) Will do so today. Blaine ----- Original Message ----- From: "Dirk Haun" To: Sent: Saturday, July 31, 2004 4:06 PM Subject: Re: [geeklog-devel] 1.3.10 to do list Blaine, >- Adding a arhive flag is no issue. >- If I add a archivetopic field then we have to have another selectbox for >this in the editform. >Do we think users will need that extra flexibilty ? I'm fine with either option. What do the others think? >So - with one click if this is in error, the story will be >auto-archived upon saving. I see your point now and have to agree. So better leave it as it was. >Only if JS is enabled will this code execute. Cool. Nice solution. bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Mon Aug 2 10:02:11 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 02 Aug 2004 09:02:11 -0500 Subject: [geeklog-devel] How's the PDF generation supposed to work? In-Reply-To: <20040731222636.9779@smtp.haun-online.de> References: <20040731222636.9779@smtp.haun-online.de> Message-ID: <410E4963.9030308@tonybibbs.com> Dirk Haun wrote: >Hmm, I thought the problems I had with the PDF generation where mostly >due to the lack of a PDF plugin for MacOS X (yes, Simon, I know there's >an unofficial one), but on closer inspection, that doesn't seem to be all ... > >So I have >$_CONF['pdf_enabled'] = 1; >$_CONF['pdf_adhoc_enabled'] = 0; > >Normal users get the PDF icon and when they click on it, they are being >told that "The PDF feature has been disabled". So why is that icon there >in the first place? > >For Admins, clicking on the PDF icon creates a new PDF file. Every time. >So after 5 clicks, I have 5 identical PDFs (for the same story). Why? > > It's a problem with the filename given to the PDF...which is currently the current unixtimestamp instead of the SID. I'll get that fixed. >After setting > >$_CONF['pdf_adhoc_enabled'] = 1; > >the same thing (multiple creation of identical PDFs) happens for normal >users, too. Again: Why? > > That setting should only enable the ad-hoc feature where you can enter any external URL and generate the PDF. >That I only get an empty browser window once pdfgenerator.php redirects >to pdfgenerator.php?cmd=getPDF&pdfFile=20040731232336946.pdf may be due >to local setup issues - still investigating that one. > >bye, Dirk > > I'll look at this all sometime today. --Tony From tony at tonybibbs.com Mon Aug 2 10:13:03 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 02 Aug 2004 09:13:03 -0500 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <002301c477d4$7374e7f0$650a10ac@XPBL2> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> Message-ID: <410E4BEF.8010809@tonybibbs.com> Well, as far as other DB connections go, that is up to the coder, obviously. GL2 should only worry about talking to the GL2 database so if you want to access another database you should, without much hassle, be able to open connections using the Creole DB layer that Propel uses: http://creole.phpdb.org/wiki/ Obviously you can still do your own with PEAR::DB or raw MySQL in your code. The DAO layer simply provides a slick way to prevent the developer from issuing raw SQL in the code...sometimes that can't be avoided and I'm sure there is probably way to issue raw SQL in unique scenarios (I need to verify that). --Tony Blaine Lang wrote: >It does look interesting and like many new libraries or models, it may be >able to improve code readability, reduce code size, and improve >re-useability but I do wonder if > 1) There are any SQL usage restrictions or more complex SQL queries that >will not work. > 2) Will you still be able to use another DB access method and direct mysql_ >calls using PHP > 3) Making GL2 too complex to understand for developers will effect it's >support > >I have had reason on several occasions to need to access another mysql >database when doing application integration. I just used the direct php >mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x >does not support this. We should consider this need in GL2 > >Blaine >----- Original Message ----- >From: "Vincent Furia" >To: >Sent: Saturday, July 31, 2004 11:17 PM >Subject: Re: [geeklog-devel] Is this rocking the boat? > > >I haven't had enough time to read up on this extensively, but it looks >promising. We just have to make sure that it fulfills all our needs >completely and won't cause any problems down the road. Also, we have >to be able to support it on the off chance that the current developers >drop the project. > >My one worry is possible performance penalties. I think we should >check how much overhead Propel requires. > >Most importantly: I want to see GL2 get moving really soon. So a >decision on this has to happen soon. Can we get enough research done >on this topic that we're not causing more delays? > >I'll spend some more time reading the Propel docs. If nothing else the >idea sounds pretty interesting. > >-Vinny > >On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > > >>Ok, I think I sent this link here, but the more I read what I see, the >>more I like it. Please take some time to read about Propel: >> >>http://propel.phpdb.org >> >>And read the user guide: >> >>http://propel.phpdb.org/docs/user_guide/ >> >>The long and short of it is this. We could implement Data Acces Objects >>that our code uses to interact with the database. DAO is a good idea no >>matter what DB abstraction layer we use and regardless if we use a tool >>like Propel. Essentially it hides the data access specifics from the >>developers. Instead developers will call simple methods on the data >>access objects and let the DAO layer do the grunt work. >> >>We could essentially use DAO to wrap the use of Propel for data acess. >> >>That said there are some pros and cons: >> >>Pros: >>1) Clean API, developers no longer have to write SQL except in really >>rare instances. >>2) Object oriented...right in line with GL2 >>3) Database changes are easier, now developers don't have to find all >>SQL effected by a database change. We simply change things at the >>Propel level (wrapped by DAO), modify our HTML templates and we are off >>to the race. >> >>Cons: >>1) It is conceptionally more complicated. Requires some ramp up. >>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even >>if you wanted to). >>3) It's in Beta. >> >>I think this tool could really save a ton of time. Please give this a >>gander and try using it against a very simply table and let me know your >>thoughts. >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Mon Aug 2 10:21:43 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 02 Aug 2004 09:21:43 -0500 Subject: [geeklog-devel] GL2 event model In-Reply-To: <002901c477d5$ca6a73d0$650a10ac@XPBL2> References: <40FEE0CD.9000901@tonybibbs.com> <20040721220312.M50280@pigstye.net> <8319e2d604072118231fa09b79@mail.gmail.com> <410AB49B.6070609@tonybibbs.com> <8319e2d604073120117cdc5d86@mail.gmail.com> <002901c477d5$ca6a73d0$650a10ac@XPBL2> Message-ID: <410E4DF7.3020604@tonybibbs.com> Getting back to my suggestion about having a standard set of plugins this is what i was eluding too. Level 10 may indicate that the plugin takes passive action. In otherwords, it will do something internally and not stop program execution. This would be transparent to the user. Level 20 may indicate the plugin may take some sort of action not tranparent to the user and the plugin will not stop program execution. Level XX indicates the plugin may fatally abort the event call and stop execution. Not sure if this makes sense or not. Obviously we would drive the levels by constants so we could tweak this. That make any sense? --Tony Blaine Lang wrote: >I like this idea of a priority field for the event model. As Vinny noted, a >2nd level of privilege for core functions is also needed. We have the issue >now in GL1.3 where we scan the plugins to see if functions are present and >it's in order of installation. So if 3 plugins have a centerblock, you have >no way of changing the order. > >I don't know if thats a good example of usage for this field - I don't think >it is so there may be another field used to control this. > >Do we need to have classes of plugins or modules as well. > - Core > - Service Providers (Messenging, Formatting) > - Interface Related > - Misc > >Just wondering if this classification would be useful. > >Blaine >----- Original Message ----- >From: "Vincent Furia" >To: >Sent: Saturday, July 31, 2004 11:11 PM >Subject: Re: [geeklog-devel] GL2 event model > > >No problem with the addition that Tony made. I also agree that we >should add a 'precedence' (what Tony call priority) field. I think >this is as easy as changing one function in the class: > >public function registerListener($events, $plugin) >--to-- >public function registerListener($events, $plugin, $precedence = 100) > >And when the $listeners field is loaded, the array of events should be >populate in order lower precedence to higher precedence. > >Where $precedence is an integer that we recommend goes from 0 - 255. >The Geeklog core then could potentially use precedence values > 255 or >< 0 if it needs to operate before or after all the other plugins. >Really, I don't think it matters what numbers we use, so any >suggestions that are more logical from a plugin developers standpoint >would be great. > >-Vinny > >On Fri, 30 Jul 2004 15:50:35 -0500, Tony Bibbs wrote: > > >>To fill in the blanks more I offer up the attached version. Only >>difference is I show how the plugins are actually called. Also, we >>might want to consider a 'priority' field for events that plugins listen >>to. Using priorities would allow plugins to get called in some sort of >>priorty fashion. I say that we come up with a standard set of >>priorities that plugins can use. This make sense? >> >>--Tony >> >> >> >>Vincent Furia wrote: >> >> >> >>>Here is what I had envisioned when I penned the Plugin API >>>documentation. It is a class that would be instantiated only once by >>>GL2 core and available globally. I prefer the per event registration >>>as it will reduce the calls the "PluginEventHanlder" will have to make >>>to listening plugins. >>> >>>-Vinny >>> >>>class PluginEventHandler { >>> >>> /** >>> * Array containing event keys and listener (arrays as) values >>> * @access private >>> * @var array >>> */ >>> private $listeners = array(); >>> >>> /** >>> * PluginEventHandler Constructor >>> * >>> * @access public >>> * >>> */ >>> function __construct() { >>> // fetch registered listeners from database, populate $listeners >>> } >>> >>> /** >>> * Register a plugin to listen for an event >>> * >>> * @access public >>> * @param mixed $event event(s) to listen for (string or array) >>> * @param string $plugin plugin to be registered as listener >>> * @return boolean true on success >>> * >>> */ >>> function registerListener($event, $plugin) { >>> // add the listener to the $listeners variable and the database >>> } >>> >>> /** >>> * Unregister a plugin from listening for an event >>> * >>> * @access public >>> * @param mixed $event event(s) to unregister (string or array) >>> * @param string $plugin plugin to be unregistered as listener >>> * @return boolean true on success >>> * >>> */ >>> function unregisterListener($event, $plugin) { >>> // remove the listener for the specified events from $listeners >>> // and the database. >>> } >>> >>> /** >>> * Get all the listeners for a specific event >>> * >>> * @access public >>> * @param string $event event to get listeners of >>> * @return array array of listeners to event $event >>> * >>> */ >>> function getListeners($event) { >>> // remove the listener for the specified events from $listeners >>> // and the database. >>> } >>> >>> /** >>> * Notify all listeners that an event has occurred >>> * >>> * @access public >>> * @param mixed $event event requiring notification >>> * @param mixed $vars event specific variables >>> * @param mixed $plugin NOTIFY_ALL, specific plugin, or array of >>> >>> >plugins > > >>> * @return mixed event specific return values (or array of) >>> * >>> */ >>> function notify($event, $vars, $plugin = NOTIFY_ALL) { >>> >>> } >>> >>>} >>> >>> >>> >>>On Wed, 21 Jul 2004 22:10:55 +0000, Tom Willett wrote: >>> >>> >>> >>> >>>>Let me get this straight. >>>> >>>>GL2 Core would make the MySubjectObserverClass >>>> >>>>$obs = new MySubjectObserverClass; >>>> >>>>then the plugin would register by somehow getting the reference to the >>>>MySubjectOvserverClass and register itself as a listener >>>> >>>>$obs->addListner($MyPlugin); >>>>or >>>>$obs->addListener($MyPlugin, $events); >>>>etc >>>> >>>>Then when a event happened GL2 Core or a plugin could notify the plugins >>>> >>>>$obs->notifyAll($event) >>>> >>>>Do I have this about right? >>>> >>>>-- >>>>Tom Willett >>>>tomw at pigstye.net >>>> >>>> >>>> >>>>---------- Original Message ----------- >>>>From: Tony Bibbs >>>>To: geeklog-devel at lists.geeklog.net >>>>Sent: Wed, 21 Jul 2004 16:31:57 -0500 >>>>Subject: [geeklog-devel] GL2 event model >>>> >>>> >>>> >>>> >>>> >>>>>The plugin API for GL2 that Vinny has drafted if surprisingly small >>>>>because we are introducing an event based model. Essentially, the GL2 >>>>>and all plugins have the option to register events that others can >>>>>listen to. To implement this I recommend an observer/observable design >>>>>pattern similar to the example below. A few things that need >>>>>discussion. First, the example below allows listening only at the >>>>>object level. The alternative is the force listening at the event >>>>> >>>>> >level > > >>>>>(in otherwords, addListener would take as a second arg an array of >>>>>events the object listens to). Any preference? General questions?: >>>>> >>>>>class MySubjectObserverClass { >>>>> private $listeners = array(); >>>>> private $listernerNextID = 0; >>>>> >>>>> // Alternative names: register, subscribe... >>>>> public function addListerner(&$obj) >>>>> { >>>>> $this->_listerners[] =& $obj; >>>>> return $this->listernerNextID++; >>>>> } >>>>> >>>>> // Alternative name: unregister, unsubscribe... >>>>> public function removeListerner($id,'even't) >>>>> { >>>>> unset($this->listerners[$id]); >>>>> } >>>>> >>>>> // Alternative name: broadcast... >>>>> public function notifyAll($event) >>>>> { >>>>> foreach ($this->listerners as $id => $obj) >>>>> { >>>>> $this->listerners[$id]->notify($event, $this); >>>>> } >>>>> } >>>>> >>>>> // Alternative name: listen... >>>>> function notify($event, &$obj) >>>>> { >>>>> switch (get_class($obj)) { >>>>> case 'blah': >>>>> ... >>>>> } >>>>> } >>>>>} >>>>> >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>------- End of Original Message ------- >>>> >>>> >>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Mon Aug 2 12:01:03 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 2 Aug 2004 12:01:03 -0400 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <410E4BEF.8010809@tonybibbs.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> Message-ID: <8319e2d60408020901ff948ac@mail.gmail.com> I just noticed this about propel (pre-installation requirements): # PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable php_xsl.dll on Windows) Is XSLT a commonly supported item? Can we depend on it being compiled in on most PHP5 installations at ISPs? -Vinny On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: > Well, as far as other DB connections go, that is up to the coder, > obviously. GL2 should only worry about talking to the GL2 database so > if you want to access another database you should, without much hassle, > be able to open connections using the Creole DB layer that Propel uses: > > http://creole.phpdb.org/wiki/ > > Obviously you can still do your own with PEAR::DB or raw MySQL in your > code. The DAO layer simply provides a slick way to prevent the > developer from issuing raw SQL in the code...sometimes that can't be > avoided and I'm sure there is probably way to issue raw SQL in unique > scenarios (I need to verify that). > > --Tony > > > > Blaine Lang wrote: > > >It does look interesting and like many new libraries or models, it may be > >able to improve code readability, reduce code size, and improve > >re-useability but I do wonder if > > 1) There are any SQL usage restrictions or more complex SQL queries that > >will not work. > > 2) Will you still be able to use another DB access method and direct mysql_ > >calls using PHP > > 3) Making GL2 too complex to understand for developers will effect it's > >support > > > >I have had reason on several occasions to need to access another mysql > >database when doing application integration. I just used the direct php > >mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x > >does not support this. We should consider this need in GL2 > > > >Blaine > >----- Original Message ----- > >From: "Vincent Furia" > >To: > >Sent: Saturday, July 31, 2004 11:17 PM > >Subject: Re: [geeklog-devel] Is this rocking the boat? > > > > > >I haven't had enough time to read up on this extensively, but it looks > >promising. We just have to make sure that it fulfills all our needs > >completely and won't cause any problems down the road. Also, we have > >to be able to support it on the off chance that the current developers > >drop the project. > > > >My one worry is possible performance penalties. I think we should > >check how much overhead Propel requires. > > > >Most importantly: I want to see GL2 get moving really soon. So a > >decision on this has to happen soon. Can we get enough research done > >on this topic that we're not causing more delays? > > > >I'll spend some more time reading the Propel docs. If nothing else the > >idea sounds pretty interesting. > > > >-Vinny > > > >On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > > > > > >>Ok, I think I sent this link here, but the more I read what I see, the > >>more I like it. Please take some time to read about Propel: > >> > >>http://propel.phpdb.org > >> > >>And read the user guide: > >> > >>http://propel.phpdb.org/docs/user_guide/ > >> > >>The long and short of it is this. We could implement Data Acces Objects > >>that our code uses to interact with the database. DAO is a good idea no > >>matter what DB abstraction layer we use and regardless if we use a tool > >>like Propel. Essentially it hides the data access specifics from the > >>developers. Instead developers will call simple methods on the data > >>access objects and let the DAO layer do the grunt work. > >> > >>We could essentially use DAO to wrap the use of Propel for data acess. > >> > >>That said there are some pros and cons: > >> > >>Pros: > >>1) Clean API, developers no longer have to write SQL except in really > >>rare instances. > >>2) Object oriented...right in line with GL2 > >>3) Database changes are easier, now developers don't have to find all > >>SQL effected by a database change. We simply change things at the > >>Propel level (wrapped by DAO), modify our HTML templates and we are off > >>to the race. > >> > >>Cons: > >>1) It is conceptionally more complicated. Requires some ramp up. > >>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even > >>if you wanted to). > >>3) It's in Beta. > >> > >>I think this tool could really save a ton of time. Please give this a > >>gander and try using it against a very simply table and let me know your > >>thoughts. > >> > >>--Tony > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Aug 2 12:10:48 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 2 Aug 2004 12:10:48 -0400 Subject: [geeklog-devel] GL2 event model In-Reply-To: <410E4DF7.3020604@tonybibbs.com> References: <40FEE0CD.9000901@tonybibbs.com> <20040721220312.M50280@pigstye.net> <8319e2d604072118231fa09b79@mail.gmail.com> <410AB49B.6070609@tonybibbs.com> <8319e2d604073120117cdc5d86@mail.gmail.com> <002901c477d5$ca6a73d0$650a10ac@XPBL2> <410E4DF7.3020604@tonybibbs.com> Message-ID: <8319e2d6040802091073b36e7e@mail.gmail.com> I think the "Level" idea is overkill, and something that is not really needed. When a developer add events to a plugin (or a the core) they should be well documented. Included in that documentation is whether event listeners should be able to take over execution (not return a value, or return something indicating they completed successfully) or if they can cause different types of errors to occur (up to fatal presumably) for that specific event. (This would be something our "approved plugin" review should be taking a look at.) Adding the "Levels" I think would begin to make things too complicated and could cause problems when it comes to plugin interaction. I think the "priority" field will be sufficient without adding complexity from the developers perspective. If I misunderstood, and these "Levels" don't represent a separate field but a way to organize the "priority" numbers, I can think of many instances where you might want passive plugins to occur before or after non-passive plugins. Forcing ordering based on action type seems like a bad idea. I hope I haven't misunderstood what you meant... -Vinny On Mon, 02 Aug 2004 09:21:43 -0500, Tony Bibbs wrote: > Getting back to my suggestion about having a standard set of plugins > this is what i was eluding too. > > Level 10 may indicate that the plugin takes passive action. In > otherwords, it will do something internally and not stop program > execution. This would be transparent to the user. > Level 20 may indicate the plugin may take some sort of action not > tranparent to the user and the plugin will not stop program execution. > Level XX indicates the plugin may fatally abort the event call and stop > execution. > > Not sure if this makes sense or not. Obviously we would drive the > levels by constants so we could tweak this. That make any sense? > > --Tony > > > > Blaine Lang wrote: > > >I like this idea of a priority field for the event model. As Vinny noted, a > >2nd level of privilege for core functions is also needed. We have the issue > >now in GL1.3 where we scan the plugins to see if functions are present and > >it's in order of installation. So if 3 plugins have a centerblock, you have > >no way of changing the order. > > > >I don't know if thats a good example of usage for this field - I don't think > >it is so there may be another field used to control this. > > > >Do we need to have classes of plugins or modules as well. > > - Core > > - Service Providers (Messenging, Formatting) > > - Interface Related > > - Misc > > > >Just wondering if this classification would be useful. > > > >Blaine > >----- Original Message ----- > >From: "Vincent Furia" > >To: > >Sent: Saturday, July 31, 2004 11:11 PM > >Subject: Re: [geeklog-devel] GL2 event model > > > > > >No problem with the addition that Tony made. I also agree that we > >should add a 'precedence' (what Tony call priority) field. I think > >this is as easy as changing one function in the class: > > > >public function registerListener($events, $plugin) > >--to-- > >public function registerListener($events, $plugin, $precedence = 100) > > > >And when the $listeners field is loaded, the array of events should be > >populate in order lower precedence to higher precedence. > > > >Where $precedence is an integer that we recommend goes from 0 - 255. > >The Geeklog core then could potentially use precedence values > 255 or > >< 0 if it needs to operate before or after all the other plugins. > >Really, I don't think it matters what numbers we use, so any > >suggestions that are more logical from a plugin developers standpoint > >would be great. > > > >-Vinny > > > >On Fri, 30 Jul 2004 15:50:35 -0500, Tony Bibbs wrote: > > > > > >>To fill in the blanks more I offer up the attached version. Only > >>difference is I show how the plugins are actually called. Also, we > >>might want to consider a 'priority' field for events that plugins listen > >>to. Using priorities would allow plugins to get called in some sort of > >>priorty fashion. I say that we come up with a standard set of > >>priorities that plugins can use. This make sense? > >> > >>--Tony > >> > >> > >> > >>Vincent Furia wrote: > >> > >> > >> > >>>Here is what I had envisioned when I penned the Plugin API > >>>documentation. It is a class that would be instantiated only once by > >>>GL2 core and available globally. I prefer the per event registration > >>>as it will reduce the calls the "PluginEventHanlder" will have to make > >>>to listening plugins. > >>> > >>>-Vinny > >>> > >>>class PluginEventHandler { > >>> > >>> /** > >>> * Array containing event keys and listener (arrays as) values > >>> * @access private > >>> * @var array > >>> */ > >>> private $listeners = array(); > >>> > >>> /** > >>> * PluginEventHandler Constructor > >>> * > >>> * @access public > >>> * > >>> */ > >>> function __construct() { > >>> // fetch registered listeners from database, populate $listeners > >>> } > >>> > >>> /** > >>> * Register a plugin to listen for an event > >>> * > >>> * @access public > >>> * @param mixed $event event(s) to listen for (string or array) > >>> * @param string $plugin plugin to be registered as listener > >>> * @return boolean true on success > >>> * > >>> */ > >>> function registerListener($event, $plugin) { > >>> // add the listener to the $listeners variable and the database > >>> } > >>> > >>> /** > >>> * Unregister a plugin from listening for an event > >>> * > >>> * @access public > >>> * @param mixed $event event(s) to unregister (string or array) > >>> * @param string $plugin plugin to be unregistered as listener > >>> * @return boolean true on success > >>> * > >>> */ > >>> function unregisterListener($event, $plugin) { > >>> // remove the listener for the specified events from $listeners > >>> // and the database. > >>> } > >>> > >>> /** > >>> * Get all the listeners for a specific event > >>> * > >>> * @access public > >>> * @param string $event event to get listeners of > >>> * @return array array of listeners to event $event > >>> * > >>> */ > >>> function getListeners($event) { > >>> // remove the listener for the specified events from $listeners > >>> // and the database. > >>> } > >>> > >>> /** > >>> * Notify all listeners that an event has occurred > >>> * > >>> * @access public > >>> * @param mixed $event event requiring notification > >>> * @param mixed $vars event specific variables > >>> * @param mixed $plugin NOTIFY_ALL, specific plugin, or array of > >>> > >>> > >plugins > > > > > >>> * @return mixed event specific return values (or array of) > >>> * > >>> */ > >>> function notify($event, $vars, $plugin = NOTIFY_ALL) { > >>> > >>> } > >>> > >>>} > >>> > >>> > >>> > >>>On Wed, 21 Jul 2004 22:10:55 +0000, Tom Willett wrote: > >>> > >>> > >>> > >>> > >>>>Let me get this straight. > >>>> > >>>>GL2 Core would make the MySubjectObserverClass > >>>> > >>>>$obs = new MySubjectObserverClass; > >>>> > >>>>then the plugin would register by somehow getting the reference to the > >>>>MySubjectOvserverClass and register itself as a listener > >>>> > >>>>$obs->addListner($MyPlugin); > >>>>or > >>>>$obs->addListener($MyPlugin, $events); > >>>>etc > >>>> > >>>>Then when a event happened GL2 Core or a plugin could notify the plugins > >>>> > >>>>$obs->notifyAll($event) > >>>> > >>>>Do I have this about right? > >>>> > >>>>-- > >>>>Tom Willett > >>>>tomw at pigstye.net > >>>> > >>>> > >>>> > >>>>---------- Original Message ----------- > >>>>From: Tony Bibbs > >>>>To: geeklog-devel at lists.geeklog.net > >>>>Sent: Wed, 21 Jul 2004 16:31:57 -0500 > >>>>Subject: [geeklog-devel] GL2 event model > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>The plugin API for GL2 that Vinny has drafted if surprisingly small > >>>>>because we are introducing an event based model. Essentially, the GL2 > >>>>>and all plugins have the option to register events that others can > >>>>>listen to. To implement this I recommend an observer/observable design > >>>>>pattern similar to the example below. A few things that need > >>>>>discussion. First, the example below allows listening only at the > >>>>>object level. The alternative is the force listening at the event > >>>>> > >>>>> > >level > > > > > >>>>>(in otherwords, addListener would take as a second arg an array of > >>>>>events the object listens to). Any preference? General questions?: > >>>>> > >>>>>class MySubjectObserverClass { > >>>>> private $listeners = array(); > >>>>> private $listernerNextID = 0; > >>>>> > >>>>> // Alternative names: register, subscribe... > >>>>> public function addListerner(&$obj) > >>>>> { > >>>>> $this->_listerners[] =& $obj; > >>>>> return $this->listernerNextID++; > >>>>> } > >>>>> > >>>>> // Alternative name: unregister, unsubscribe... > >>>>> public function removeListerner($id,'even't) > >>>>> { > >>>>> unset($this->listerners[$id]); > >>>>> } > >>>>> > >>>>> // Alternative name: broadcast... > >>>>> public function notifyAll($event) > >>>>> { > >>>>> foreach ($this->listerners as $id => $obj) > >>>>> { > >>>>> $this->listerners[$id]->notify($event, $this); > >>>>> } > >>>>> } > >>>>> > >>>>> // Alternative name: listen... > >>>>> function notify($event, &$obj) > >>>>> { > >>>>> switch (get_class($obj)) { > >>>>> case 'blah': > >>>>> ... > >>>>> } > >>>>> } > >>>>>} > >>>>> > >>>>>_______________________________________________ > >>>>>geeklog-devel mailing list > >>>>>geeklog-devel at lists.geeklog.net > >>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>> > >>>>> > >>>>> > >>>>> > >>>>------- End of Original Message ------- > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Mon Aug 2 12:23:30 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 02 Aug 2004 11:23:30 -0500 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <8319e2d60408020901ff948ac@mail.gmail.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> Message-ID: <410E6A82.4050205@tonybibbs.com> Good question. I know the new XML support in PHP5 is included by default. I'd have to search the manual to see if it enabled by default. If it is, let's plan on using it. If not, I think this is probably a deal killer. --Tony Vincent Furia wrote: >I just noticed this about propel (pre-installation requirements): > ># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable >php_xsl.dll on Windows) > >Is XSLT a commonly supported item? Can we depend on it being compiled >in on most PHP5 installations at ISPs? > >-Vinny > > >On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: > > >>Well, as far as other DB connections go, that is up to the coder, >>obviously. GL2 should only worry about talking to the GL2 database so >>if you want to access another database you should, without much hassle, >>be able to open connections using the Creole DB layer that Propel uses: >> >>http://creole.phpdb.org/wiki/ >> >>Obviously you can still do your own with PEAR::DB or raw MySQL in your >>code. The DAO layer simply provides a slick way to prevent the >>developer from issuing raw SQL in the code...sometimes that can't be >>avoided and I'm sure there is probably way to issue raw SQL in unique >>scenarios (I need to verify that). >> >>--Tony >> >> >> >>Blaine Lang wrote: >> >> >> >>>It does look interesting and like many new libraries or models, it may be >>>able to improve code readability, reduce code size, and improve >>>re-useability but I do wonder if >>>1) There are any SQL usage restrictions or more complex SQL queries that >>>will not work. >>>2) Will you still be able to use another DB access method and direct mysql_ >>>calls using PHP >>>3) Making GL2 too complex to understand for developers will effect it's >>>support >>> >>>I have had reason on several occasions to need to access another mysql >>>database when doing application integration. I just used the direct php >>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x >>>does not support this. We should consider this need in GL2 >>> >>>Blaine >>>----- Original Message ----- >>>From: "Vincent Furia" >>>To: >>>Sent: Saturday, July 31, 2004 11:17 PM >>>Subject: Re: [geeklog-devel] Is this rocking the boat? >>> >>> >>>I haven't had enough time to read up on this extensively, but it looks >>>promising. We just have to make sure that it fulfills all our needs >>>completely and won't cause any problems down the road. Also, we have >>>to be able to support it on the off chance that the current developers >>>drop the project. >>> >>>My one worry is possible performance penalties. I think we should >>>check how much overhead Propel requires. >>> >>>Most importantly: I want to see GL2 get moving really soon. So a >>>decision on this has to happen soon. Can we get enough research done >>>on this topic that we're not causing more delays? >>> >>>I'll spend some more time reading the Propel docs. If nothing else the >>>idea sounds pretty interesting. >>> >>>-Vinny >>> >>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: >>> >>> >>> >>> >>>>Ok, I think I sent this link here, but the more I read what I see, the >>>>more I like it. Please take some time to read about Propel: >>>> >>>>http://propel.phpdb.org >>>> >>>>And read the user guide: >>>> >>>>http://propel.phpdb.org/docs/user_guide/ >>>> >>>>The long and short of it is this. We could implement Data Acces Objects >>>>that our code uses to interact with the database. DAO is a good idea no >>>>matter what DB abstraction layer we use and regardless if we use a tool >>>>like Propel. Essentially it hides the data access specifics from the >>>>developers. Instead developers will call simple methods on the data >>>>access objects and let the DAO layer do the grunt work. >>>> >>>>We could essentially use DAO to wrap the use of Propel for data acess. >>>> >>>>That said there are some pros and cons: >>>> >>>>Pros: >>>>1) Clean API, developers no longer have to write SQL except in really >>>>rare instances. >>>>2) Object oriented...right in line with GL2 >>>>3) Database changes are easier, now developers don't have to find all >>>>SQL effected by a database change. We simply change things at the >>>>Propel level (wrapped by DAO), modify our HTML templates and we are off >>>>to the race. >>>> >>>>Cons: >>>>1) It is conceptionally more complicated. Requires some ramp up. >>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even >>>>if you wanted to). >>>>3) It's in Beta. >>>> >>>>I think this tool could really save a ton of time. Please give this a >>>>gander and try using it against a very simply table and let me know your >>>>thoughts. >>>> >>>>--Tony >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Mon Aug 2 12:55:51 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 2 Aug 2004 12:55:51 -0400 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <410E6A82.4050205@tonybibbs.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> Message-ID: <8319e2d604080209552b70ebd5@mail.gmail.com> I just looked in PHP 5's configure file. By default, XSLT is included if the supporting libraries are available on the host operating system. Is XSLT included with most linux distributions? What about Windows? Do standard binary installs of PHP 5 on Windows include XSLT? -Vinny On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: > Good question. I know the new XML support in PHP5 is included by > default. I'd have to search the manual to see if it enabled by > default. If it is, let's plan on using it. If not, I think this is > probably a deal killer. > > --Tony > > > > Vincent Furia wrote: > > >I just noticed this about propel (pre-installation requirements): > > > ># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable > >php_xsl.dll on Windows) > > > >Is XSLT a commonly supported item? Can we depend on it being compiled > >in on most PHP5 installations at ISPs? > > > >-Vinny > > > > > >On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: > > > > > >>Well, as far as other DB connections go, that is up to the coder, > >>obviously. GL2 should only worry about talking to the GL2 database so > >>if you want to access another database you should, without much hassle, > >>be able to open connections using the Creole DB layer that Propel uses: > >> > >>http://creole.phpdb.org/wiki/ > >> > >>Obviously you can still do your own with PEAR::DB or raw MySQL in your > >>code. The DAO layer simply provides a slick way to prevent the > >>developer from issuing raw SQL in the code...sometimes that can't be > >>avoided and I'm sure there is probably way to issue raw SQL in unique > >>scenarios (I need to verify that). > >> > >>--Tony > >> > >> > >> > >>Blaine Lang wrote: > >> > >> > >> > >>>It does look interesting and like many new libraries or models, it may be > >>>able to improve code readability, reduce code size, and improve > >>>re-useability but I do wonder if > >>>1) There are any SQL usage restrictions or more complex SQL queries that > >>>will not work. > >>>2) Will you still be able to use another DB access method and direct mysql_ > >>>calls using PHP > >>>3) Making GL2 too complex to understand for developers will effect it's > >>>support > >>> > >>>I have had reason on several occasions to need to access another mysql > >>>database when doing application integration. I just used the direct php > >>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x > >>>does not support this. We should consider this need in GL2 > >>> > >>>Blaine > >>>----- Original Message ----- > >>>From: "Vincent Furia" > >>>To: > >>>Sent: Saturday, July 31, 2004 11:17 PM > >>>Subject: Re: [geeklog-devel] Is this rocking the boat? > >>> > >>> > >>>I haven't had enough time to read up on this extensively, but it looks > >>>promising. We just have to make sure that it fulfills all our needs > >>>completely and won't cause any problems down the road. Also, we have > >>>to be able to support it on the off chance that the current developers > >>>drop the project. > >>> > >>>My one worry is possible performance penalties. I think we should > >>>check how much overhead Propel requires. > >>> > >>>Most importantly: I want to see GL2 get moving really soon. So a > >>>decision on this has to happen soon. Can we get enough research done > >>>on this topic that we're not causing more delays? > >>> > >>>I'll spend some more time reading the Propel docs. If nothing else the > >>>idea sounds pretty interesting. > >>> > >>>-Vinny > >>> > >>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > >>> > >>> > >>> > >>> > >>>>Ok, I think I sent this link here, but the more I read what I see, the > >>>>more I like it. Please take some time to read about Propel: > >>>> > >>>>http://propel.phpdb.org > >>>> > >>>>And read the user guide: > >>>> > >>>>http://propel.phpdb.org/docs/user_guide/ > >>>> > >>>>The long and short of it is this. We could implement Data Acces Objects > >>>>that our code uses to interact with the database. DAO is a good idea no > >>>>matter what DB abstraction layer we use and regardless if we use a tool > >>>>like Propel. Essentially it hides the data access specifics from the > >>>>developers. Instead developers will call simple methods on the data > >>>>access objects and let the DAO layer do the grunt work. > >>>> > >>>>We could essentially use DAO to wrap the use of Propel for data acess. > >>>> > >>>>That said there are some pros and cons: > >>>> > >>>>Pros: > >>>>1) Clean API, developers no longer have to write SQL except in really > >>>>rare instances. > >>>>2) Object oriented...right in line with GL2 > >>>>3) Database changes are easier, now developers don't have to find all > >>>>SQL effected by a database change. We simply change things at the > >>>>Propel level (wrapped by DAO), modify our HTML templates and we are off > >>>>to the race. > >>>> > >>>>Cons: > >>>>1) It is conceptionally more complicated. Requires some ramp up. > >>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even > >>>>if you wanted to). > >>>>3) It's in Beta. > >>>> > >>>>I think this tool could really save a ton of time. Please give this a > >>>>gander and try using it against a very simply table and let me know your > >>>>thoughts. > >>>> > >>>>--Tony > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Aug 2 12:55:51 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 2 Aug 2004 12:55:51 -0400 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <410E6A82.4050205@tonybibbs.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> Message-ID: <8319e2d604080209552b70ebd5@mail.gmail.com> I just looked in PHP 5's configure file. By default, XSLT is included if the supporting libraries are available on the host operating system. Is XSLT included with most linux distributions? What about Windows? Do standard binary installs of PHP 5 on Windows include XSLT? -Vinny On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: > Good question. I know the new XML support in PHP5 is included by > default. I'd have to search the manual to see if it enabled by > default. If it is, let's plan on using it. If not, I think this is > probably a deal killer. > > --Tony > > > > Vincent Furia wrote: > > >I just noticed this about propel (pre-installation requirements): > > > ># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable > >php_xsl.dll on Windows) > > > >Is XSLT a commonly supported item? Can we depend on it being compiled > >in on most PHP5 installations at ISPs? > > > >-Vinny > > > > > >On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: > > > > > >>Well, as far as other DB connections go, that is up to the coder, > >>obviously. GL2 should only worry about talking to the GL2 database so > >>if you want to access another database you should, without much hassle, > >>be able to open connections using the Creole DB layer that Propel uses: > >> > >>http://creole.phpdb.org/wiki/ > >> > >>Obviously you can still do your own with PEAR::DB or raw MySQL in your > >>code. The DAO layer simply provides a slick way to prevent the > >>developer from issuing raw SQL in the code...sometimes that can't be > >>avoided and I'm sure there is probably way to issue raw SQL in unique > >>scenarios (I need to verify that). > >> > >>--Tony > >> > >> > >> > >>Blaine Lang wrote: > >> > >> > >> > >>>It does look interesting and like many new libraries or models, it may be > >>>able to improve code readability, reduce code size, and improve > >>>re-useability but I do wonder if > >>>1) There are any SQL usage restrictions or more complex SQL queries that > >>>will not work. > >>>2) Will you still be able to use another DB access method and direct mysql_ > >>>calls using PHP > >>>3) Making GL2 too complex to understand for developers will effect it's > >>>support > >>> > >>>I have had reason on several occasions to need to access another mysql > >>>database when doing application integration. I just used the direct php > >>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x > >>>does not support this. We should consider this need in GL2 > >>> > >>>Blaine > >>>----- Original Message ----- > >>>From: "Vincent Furia" > >>>To: > >>>Sent: Saturday, July 31, 2004 11:17 PM > >>>Subject: Re: [geeklog-devel] Is this rocking the boat? > >>> > >>> > >>>I haven't had enough time to read up on this extensively, but it looks > >>>promising. We just have to make sure that it fulfills all our needs > >>>completely and won't cause any problems down the road. Also, we have > >>>to be able to support it on the off chance that the current developers > >>>drop the project. > >>> > >>>My one worry is possible performance penalties. I think we should > >>>check how much overhead Propel requires. > >>> > >>>Most importantly: I want to see GL2 get moving really soon. So a > >>>decision on this has to happen soon. Can we get enough research done > >>>on this topic that we're not causing more delays? > >>> > >>>I'll spend some more time reading the Propel docs. If nothing else the > >>>idea sounds pretty interesting. > >>> > >>>-Vinny > >>> > >>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > >>> > >>> > >>> > >>> > >>>>Ok, I think I sent this link here, but the more I read what I see, the > >>>>more I like it. Please take some time to read about Propel: > >>>> > >>>>http://propel.phpdb.org > >>>> > >>>>And read the user guide: > >>>> > >>>>http://propel.phpdb.org/docs/user_guide/ > >>>> > >>>>The long and short of it is this. We could implement Data Acces Objects > >>>>that our code uses to interact with the database. DAO is a good idea no > >>>>matter what DB abstraction layer we use and regardless if we use a tool > >>>>like Propel. Essentially it hides the data access specifics from the > >>>>developers. Instead developers will call simple methods on the data > >>>>access objects and let the DAO layer do the grunt work. > >>>> > >>>>We could essentially use DAO to wrap the use of Propel for data acess. > >>>> > >>>>That said there are some pros and cons: > >>>> > >>>>Pros: > >>>>1) Clean API, developers no longer have to write SQL except in really > >>>>rare instances. > >>>>2) Object oriented...right in line with GL2 > >>>>3) Database changes are easier, now developers don't have to find all > >>>>SQL effected by a database change. We simply change things at the > >>>>Propel level (wrapped by DAO), modify our HTML templates and we are off > >>>>to the race. > >>>> > >>>>Cons: > >>>>1) It is conceptionally more complicated. Requires some ramp up. > >>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even > >>>>if you wanted to). > >>>>3) It's in Beta. > >>>> > >>>>I think this tool could really save a ton of time. Please give this a > >>>>gander and try using it against a very simply table and let me know your > >>>>thoughts. > >>>> > >>>>--Tony > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Aug 2 12:55:51 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 2 Aug 2004 12:55:51 -0400 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <410E6A82.4050205@tonybibbs.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> Message-ID: <8319e2d604080209552b70ebd5@mail.gmail.com> I just looked in PHP 5's configure file. By default, XSLT is included if the supporting libraries are available on the host operating system. Is XSLT included with most linux distributions? What about Windows? Do standard binary installs of PHP 5 on Windows include XSLT? -Vinny On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: > Good question. I know the new XML support in PHP5 is included by > default. I'd have to search the manual to see if it enabled by > default. If it is, let's plan on using it. If not, I think this is > probably a deal killer. > > --Tony > > > > Vincent Furia wrote: > > >I just noticed this about propel (pre-installation requirements): > > > ># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable > >php_xsl.dll on Windows) > > > >Is XSLT a commonly supported item? Can we depend on it being compiled > >in on most PHP5 installations at ISPs? > > > >-Vinny > > > > > >On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: > > > > > >>Well, as far as other DB connections go, that is up to the coder, > >>obviously. GL2 should only worry about talking to the GL2 database so > >>if you want to access another database you should, without much hassle, > >>be able to open connections using the Creole DB layer that Propel uses: > >> > >>http://creole.phpdb.org/wiki/ > >> > >>Obviously you can still do your own with PEAR::DB or raw MySQL in your > >>code. The DAO layer simply provides a slick way to prevent the > >>developer from issuing raw SQL in the code...sometimes that can't be > >>avoided and I'm sure there is probably way to issue raw SQL in unique > >>scenarios (I need to verify that). > >> > >>--Tony > >> > >> > >> > >>Blaine Lang wrote: > >> > >> > >> > >>>It does look interesting and like many new libraries or models, it may be > >>>able to improve code readability, reduce code size, and improve > >>>re-useability but I do wonder if > >>>1) There are any SQL usage restrictions or more complex SQL queries that > >>>will not work. > >>>2) Will you still be able to use another DB access method and direct mysql_ > >>>calls using PHP > >>>3) Making GL2 too complex to understand for developers will effect it's > >>>support > >>> > >>>I have had reason on several occasions to need to access another mysql > >>>database when doing application integration. I just used the direct php > >>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x > >>>does not support this. We should consider this need in GL2 > >>> > >>>Blaine > >>>----- Original Message ----- > >>>From: "Vincent Furia" > >>>To: > >>>Sent: Saturday, July 31, 2004 11:17 PM > >>>Subject: Re: [geeklog-devel] Is this rocking the boat? > >>> > >>> > >>>I haven't had enough time to read up on this extensively, but it looks > >>>promising. We just have to make sure that it fulfills all our needs > >>>completely and won't cause any problems down the road. Also, we have > >>>to be able to support it on the off chance that the current developers > >>>drop the project. > >>> > >>>My one worry is possible performance penalties. I think we should > >>>check how much overhead Propel requires. > >>> > >>>Most importantly: I want to see GL2 get moving really soon. So a > >>>decision on this has to happen soon. Can we get enough research done > >>>on this topic that we're not causing more delays? > >>> > >>>I'll spend some more time reading the Propel docs. If nothing else the > >>>idea sounds pretty interesting. > >>> > >>>-Vinny > >>> > >>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > >>> > >>> > >>> > >>> > >>>>Ok, I think I sent this link here, but the more I read what I see, the > >>>>more I like it. Please take some time to read about Propel: > >>>> > >>>>http://propel.phpdb.org > >>>> > >>>>And read the user guide: > >>>> > >>>>http://propel.phpdb.org/docs/user_guide/ > >>>> > >>>>The long and short of it is this. We could implement Data Acces Objects > >>>>that our code uses to interact with the database. DAO is a good idea no > >>>>matter what DB abstraction layer we use and regardless if we use a tool > >>>>like Propel. Essentially it hides the data access specifics from the > >>>>developers. Instead developers will call simple methods on the data > >>>>access objects and let the DAO layer do the grunt work. > >>>> > >>>>We could essentially use DAO to wrap the use of Propel for data acess. > >>>> > >>>>That said there are some pros and cons: > >>>> > >>>>Pros: > >>>>1) Clean API, developers no longer have to write SQL except in really > >>>>rare instances. > >>>>2) Object oriented...right in line with GL2 > >>>>3) Database changes are easier, now developers don't have to find all > >>>>SQL effected by a database change. We simply change things at the > >>>>Propel level (wrapped by DAO), modify our HTML templates and we are off > >>>>to the race. > >>>> > >>>>Cons: > >>>>1) It is conceptionally more complicated. Requires some ramp up. > >>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even > >>>>if you wanted to). > >>>>3) It's in Beta. > >>>> > >>>>I think this tool could really save a ton of time. Please give this a > >>>>gander and try using it against a very simply table and let me know your > >>>>thoughts. > >>>> > >>>>--Tony > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Mon Aug 2 14:31:30 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 02 Aug 2004 13:31:30 -0500 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <8319e2d604080209552b70ebd5@mail.gmail.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> <8319e2d604080209552b70ebd5@mail.gmail.com> Message-ID: <410E8882.1080801@tonybibbs.com> On linux it is libxslt I'm guessing. Yes, I already have it. However, I have compiled PHP and provided neither the --with-xsl nor the --without-xsl and the xsl related functions listed in the PHP manual don't work. My guess is this is because the XSL support is still listed as 'experimental' (as is the SOAP support). We should follow-up with the PHP folks to see if they plan on including it as you described (i.e. only if the libraries are already installed) once they are deemed 'stable'. Also, it's probaby worth noting that this would all work drastically different in the case of windows. How, I'm not sure but since they typcially don't install from source, they most likely will have additional steps. --Tony Vincent Furia wrote: >I just looked in PHP 5's configure file. By default, XSLT is included >if the supporting libraries are available on the host operating >system. Is XSLT included with most linux distributions? What about >Windows? Do standard binary installs of PHP 5 on Windows include >XSLT? > >-Vinny > >On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: > > >>Good question. I know the new XML support in PHP5 is included by >>default. I'd have to search the manual to see if it enabled by >>default. If it is, let's plan on using it. If not, I think this is >>probably a deal killer. >> >>--Tony >> >> >> >>Vincent Furia wrote: >> >> >> >>>I just noticed this about propel (pre-installation requirements): >>> >>># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable >>>php_xsl.dll on Windows) >>> >>>Is XSLT a commonly supported item? Can we depend on it being compiled >>>in on most PHP5 installations at ISPs? >>> >>>-Vinny >>> >>> >>>On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: >>> >>> >>> >>> >>>>Well, as far as other DB connections go, that is up to the coder, >>>>obviously. GL2 should only worry about talking to the GL2 database so >>>>if you want to access another database you should, without much hassle, >>>>be able to open connections using the Creole DB layer that Propel uses: >>>> >>>>http://creole.phpdb.org/wiki/ >>>> >>>>Obviously you can still do your own with PEAR::DB or raw MySQL in your >>>>code. The DAO layer simply provides a slick way to prevent the >>>>developer from issuing raw SQL in the code...sometimes that can't be >>>>avoided and I'm sure there is probably way to issue raw SQL in unique >>>>scenarios (I need to verify that). >>>> >>>>--Tony >>>> >>>> >>>> >>>>Blaine Lang wrote: >>>> >>>> >>>> >>>> >>>> >>>>>It does look interesting and like many new libraries or models, it may be >>>>>able to improve code readability, reduce code size, and improve >>>>>re-useability but I do wonder if >>>>>1) There are any SQL usage restrictions or more complex SQL queries that >>>>>will not work. >>>>>2) Will you still be able to use another DB access method and direct mysql_ >>>>>calls using PHP >>>>>3) Making GL2 too complex to understand for developers will effect it's >>>>>support >>>>> >>>>>I have had reason on several occasions to need to access another mysql >>>>>database when doing application integration. I just used the direct php >>>>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x >>>>>does not support this. We should consider this need in GL2 >>>>> >>>>>Blaine >>>>>----- Original Message ----- >>>>>From: "Vincent Furia" >>>>>To: >>>>>Sent: Saturday, July 31, 2004 11:17 PM >>>>>Subject: Re: [geeklog-devel] Is this rocking the boat? >>>>> >>>>> >>>>>I haven't had enough time to read up on this extensively, but it looks >>>>>promising. We just have to make sure that it fulfills all our needs >>>>>completely and won't cause any problems down the road. Also, we have >>>>>to be able to support it on the off chance that the current developers >>>>>drop the project. >>>>> >>>>>My one worry is possible performance penalties. I think we should >>>>>check how much overhead Propel requires. >>>>> >>>>>Most importantly: I want to see GL2 get moving really soon. So a >>>>>decision on this has to happen soon. Can we get enough research done >>>>>on this topic that we're not causing more delays? >>>>> >>>>>I'll spend some more time reading the Propel docs. If nothing else the >>>>>idea sounds pretty interesting. >>>>> >>>>>-Vinny >>>>> >>>>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Ok, I think I sent this link here, but the more I read what I see, the >>>>>>more I like it. Please take some time to read about Propel: >>>>>> >>>>>>http://propel.phpdb.org >>>>>> >>>>>>And read the user guide: >>>>>> >>>>>>http://propel.phpdb.org/docs/user_guide/ >>>>>> >>>>>>The long and short of it is this. We could implement Data Acces Objects >>>>>>that our code uses to interact with the database. DAO is a good idea no >>>>>>matter what DB abstraction layer we use and regardless if we use a tool >>>>>>like Propel. Essentially it hides the data access specifics from the >>>>>>developers. Instead developers will call simple methods on the data >>>>>>access objects and let the DAO layer do the grunt work. >>>>>> >>>>>>We could essentially use DAO to wrap the use of Propel for data acess. >>>>>> >>>>>>That said there are some pros and cons: >>>>>> >>>>>>Pros: >>>>>>1) Clean API, developers no longer have to write SQL except in really >>>>>>rare instances. >>>>>>2) Object oriented...right in line with GL2 >>>>>>3) Database changes are easier, now developers don't have to find all >>>>>>SQL effected by a database change. We simply change things at the >>>>>>Propel level (wrapped by DAO), modify our HTML templates and we are off >>>>>>to the race. >>>>>> >>>>>>Cons: >>>>>>1) It is conceptionally more complicated. Requires some ramp up. >>>>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even >>>>>>if you wanted to). >>>>>>3) It's in Beta. >>>>>> >>>>>>I think this tool could really save a ton of time. Please give this a >>>>>>gander and try using it against a very simply table and let me know your >>>>>>thoughts. >>>>>> >>>>>>--Tony >>>>>>_______________________________________________ >>>>>>geeklog-devel mailing list >>>>>>geeklog-devel at lists.geeklog.net >>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Mon Aug 2 14:31:06 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 2 Aug 2004 14:31:06 -0400 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <410E8882.1080801@tonybibbs.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> <8319e2d604080209552b70ebd5@mail.gmail.com> <410E8882.1080801@tonybibbs.com> Message-ID: <8319e2d604080211318f364e@mail.gmail.com> >From php.net: http://us2.php.net/xslt This PHP extension provides a processor independent API to XSLT transformations. Currently this extension only supports the Sablotron library from the Ginger Alliance. Support is planned for other libraries, such as the Xalan library or the libxslt library. My reading of this is only Sablotron is supported, not libxslt. -Vinny On Mon, 02 Aug 2004 13:31:30 -0500, Tony Bibbs wrote: > On linux it is libxslt I'm guessing. Yes, I already have it. However, > I have compiled PHP and provided neither the --with-xsl nor the > --without-xsl and the xsl related functions listed in the PHP manual > don't work. My guess is this is because the XSL support is still listed > as 'experimental' (as is the SOAP support). We should follow-up with > the PHP folks to see if they plan on including it as you described (i.e. > only if the libraries are already installed) once they are deemed > 'stable'. > > Also, it's probaby worth noting that this would all work drastically > different in the case of windows. How, I'm not sure but since they > typcially don't install from source, they most likely will have > additional steps. > > > > --Tony > > Vincent Furia wrote: > > >I just looked in PHP 5's configure file. By default, XSLT is included > >if the supporting libraries are available on the host operating > >system. Is XSLT included with most linux distributions? What about > >Windows? Do standard binary installs of PHP 5 on Windows include > >XSLT? > > > >-Vinny > > > >On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: > > > > > >>Good question. I know the new XML support in PHP5 is included by > >>default. I'd have to search the manual to see if it enabled by > >>default. If it is, let's plan on using it. If not, I think this is > >>probably a deal killer. > >> > >>--Tony > >> > >> > >> > >>Vincent Furia wrote: > >> > >> > >> > >>>I just noticed this about propel (pre-installation requirements): > >>> > >>># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable > >>>php_xsl.dll on Windows) > >>> > >>>Is XSLT a commonly supported item? Can we depend on it being compiled > >>>in on most PHP5 installations at ISPs? > >>> > >>>-Vinny > >>> > >>> > >>>On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: > >>> > >>> > >>> > >>> > >>>>Well, as far as other DB connections go, that is up to the coder, > >>>>obviously. GL2 should only worry about talking to the GL2 database so > >>>>if you want to access another database you should, without much hassle, > >>>>be able to open connections using the Creole DB layer that Propel uses: > >>>> > >>>>http://creole.phpdb.org/wiki/ > >>>> > >>>>Obviously you can still do your own with PEAR::DB or raw MySQL in your > >>>>code. The DAO layer simply provides a slick way to prevent the > >>>>developer from issuing raw SQL in the code...sometimes that can't be > >>>>avoided and I'm sure there is probably way to issue raw SQL in unique > >>>>scenarios (I need to verify that). > >>>> > >>>>--Tony > >>>> > >>>> > >>>> > >>>>Blaine Lang wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>It does look interesting and like many new libraries or models, it may be > >>>>>able to improve code readability, reduce code size, and improve > >>>>>re-useability but I do wonder if > >>>>>1) There are any SQL usage restrictions or more complex SQL queries that > >>>>>will not work. > >>>>>2) Will you still be able to use another DB access method and direct mysql_ > >>>>>calls using PHP > >>>>>3) Making GL2 too complex to understand for developers will effect it's > >>>>>support > >>>>> > >>>>>I have had reason on several occasions to need to access another mysql > >>>>>database when doing application integration. I just used the direct php > >>>>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x > >>>>>does not support this. We should consider this need in GL2 > >>>>> > >>>>>Blaine > >>>>>----- Original Message ----- > >>>>>From: "Vincent Furia" > >>>>>To: > >>>>>Sent: Saturday, July 31, 2004 11:17 PM > >>>>>Subject: Re: [geeklog-devel] Is this rocking the boat? > >>>>> > >>>>> > >>>>>I haven't had enough time to read up on this extensively, but it looks > >>>>>promising. We just have to make sure that it fulfills all our needs > >>>>>completely and won't cause any problems down the road. Also, we have > >>>>>to be able to support it on the off chance that the current developers > >>>>>drop the project. > >>>>> > >>>>>My one worry is possible performance penalties. I think we should > >>>>>check how much overhead Propel requires. > >>>>> > >>>>>Most importantly: I want to see GL2 get moving really soon. So a > >>>>>decision on this has to happen soon. Can we get enough research done > >>>>>on this topic that we're not causing more delays? > >>>>> > >>>>>I'll spend some more time reading the Propel docs. If nothing else the > >>>>>idea sounds pretty interesting. > >>>>> > >>>>>-Vinny > >>>>> > >>>>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Ok, I think I sent this link here, but the more I read what I see, the > >>>>>>more I like it. Please take some time to read about Propel: > >>>>>> > >>>>>>http://propel.phpdb.org > >>>>>> > >>>>>>And read the user guide: > >>>>>> > >>>>>>http://propel.phpdb.org/docs/user_guide/ > >>>>>> > >>>>>>The long and short of it is this. We could implement Data Acces Objects > >>>>>>that our code uses to interact with the database. DAO is a good idea no > >>>>>>matter what DB abstraction layer we use and regardless if we use a tool > >>>>>>like Propel. Essentially it hides the data access specifics from the > >>>>>>developers. Instead developers will call simple methods on the data > >>>>>>access objects and let the DAO layer do the grunt work. > >>>>>> > >>>>>>We could essentially use DAO to wrap the use of Propel for data acess. > >>>>>> > >>>>>>That said there are some pros and cons: > >>>>>> > >>>>>>Pros: > >>>>>>1) Clean API, developers no longer have to write SQL except in really > >>>>>>rare instances. > >>>>>>2) Object oriented...right in line with GL2 > >>>>>>3) Database changes are easier, now developers don't have to find all > >>>>>>SQL effected by a database change. We simply change things at the > >>>>>>Propel level (wrapped by DAO), modify our HTML templates and we are off > >>>>>>to the race. > >>>>>> > >>>>>>Cons: > >>>>>>1) It is conceptionally more complicated. Requires some ramp up. > >>>>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even > >>>>>>if you wanted to). > >>>>>>3) It's in Beta. > >>>>>> > >>>>>>I think this tool could really save a ton of time. Please give this a > >>>>>>gander and try using it against a very simply table and let me know your > >>>>>>thoughts. > >>>>>> > >>>>>>--Tony > >>>>>>_______________________________________________ > >>>>>>geeklog-devel mailing list > >>>>>>geeklog-devel at lists.geeklog.net > >>>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>_______________________________________________ > >>>>>geeklog-devel mailing list > >>>>>geeklog-devel at lists.geeklog.net > >>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>> > >>>>>_______________________________________________ > >>>>>geeklog-devel mailing list > >>>>>geeklog-devel at lists.geeklog.net > >>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Mon Aug 2 14:51:33 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 02 Aug 2004 13:51:33 -0500 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <8319e2d604080211318f364e@mail.gmail.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> <8319e2d604080209552b70ebd5@mail.gmail.com> <410E8882.1080801@tonybibbs.com> <8319e2d604080211318f364e@mail.gmail.com> Message-ID: <410E8D35.4090508@tonybibbs.com> Hrm, sticky situation. I guess we could try and get a hold of the authors of this XSL stuff and see if they have any timelines for updates to support other libraries. It would have been nice if the Propel folks would have added optional support for the XSL support in PEAR. --Tony Vincent Furia wrote: >>From php.net: > >http://us2.php.net/xslt > This PHP extension provides a processor independent API to XSLT >transformations. Currently this extension only supports the Sablotron >library from the Ginger Alliance. Support is planned for other >libraries, such as the Xalan library or the libxslt library. > >My reading of this is only Sablotron is supported, not libxslt. > >-Vinny > > >On Mon, 02 Aug 2004 13:31:30 -0500, Tony Bibbs wrote: > > >>On linux it is libxslt I'm guessing. Yes, I already have it. However, >>I have compiled PHP and provided neither the --with-xsl nor the >>--without-xsl and the xsl related functions listed in the PHP manual >>don't work. My guess is this is because the XSL support is still listed >>as 'experimental' (as is the SOAP support). We should follow-up with >>the PHP folks to see if they plan on including it as you described (i.e. >>only if the libraries are already installed) once they are deemed >>'stable'. >> >>Also, it's probaby worth noting that this would all work drastically >>different in the case of windows. How, I'm not sure but since they >>typcially don't install from source, they most likely will have >>additional steps. >> >> >> >>--Tony >> >>Vincent Furia wrote: >> >> >> >>>I just looked in PHP 5's configure file. By default, XSLT is included >>>if the supporting libraries are available on the host operating >>>system. Is XSLT included with most linux distributions? What about >>>Windows? Do standard binary installs of PHP 5 on Windows include >>>XSLT? >>> >>>-Vinny >>> >>>On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: >>> >>> >>> >>> >>>>Good question. I know the new XML support in PHP5 is included by >>>>default. I'd have to search the manual to see if it enabled by >>>>default. If it is, let's plan on using it. If not, I think this is >>>>probably a deal killer. >>>> >>>>--Tony >>>> >>>> >>>> >>>>Vincent Furia wrote: >>>> >>>> >>>> >>>> >>>> >>>>>I just noticed this about propel (pre-installation requirements): >>>>> >>>>># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable >>>>>php_xsl.dll on Windows) >>>>> >>>>>Is XSLT a commonly supported item? Can we depend on it being compiled >>>>>in on most PHP5 installations at ISPs? >>>>> >>>>>-Vinny >>>>> >>>>> >>>>>On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Well, as far as other DB connections go, that is up to the coder, >>>>>>obviously. GL2 should only worry about talking to the GL2 database so >>>>>>if you want to access another database you should, without much hassle, >>>>>>be able to open connections using the Creole DB layer that Propel uses: >>>>>> >>>>>>http://creole.phpdb.org/wiki/ >>>>>> >>>>>>Obviously you can still do your own with PEAR::DB or raw MySQL in your >>>>>>code. The DAO layer simply provides a slick way to prevent the >>>>>>developer from issuing raw SQL in the code...sometimes that can't be >>>>>>avoided and I'm sure there is probably way to issue raw SQL in unique >>>>>>scenarios (I need to verify that). >>>>>> >>>>>>--Tony >>>>>> >>>>>> >>>>>> >>>>>>Blaine Lang wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>It does look interesting and like many new libraries or models, it may be >>>>>>>able to improve code readability, reduce code size, and improve >>>>>>>re-useability but I do wonder if >>>>>>>1) There are any SQL usage restrictions or more complex SQL queries that >>>>>>>will not work. >>>>>>>2) Will you still be able to use another DB access method and direct mysql_ >>>>>>>calls using PHP >>>>>>>3) Making GL2 too complex to understand for developers will effect it's >>>>>>>support >>>>>>> >>>>>>>I have had reason on several occasions to need to access another mysql >>>>>>>database when doing application integration. I just used the direct php >>>>>>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x >>>>>>>does not support this. We should consider this need in GL2 >>>>>>> >>>>>>>Blaine >>>>>>>----- Original Message ----- >>>>>>>From: "Vincent Furia" >>>>>>>To: >>>>>>>Sent: Saturday, July 31, 2004 11:17 PM >>>>>>>Subject: Re: [geeklog-devel] Is this rocking the boat? >>>>>>> >>>>>>> >>>>>>>I haven't had enough time to read up on this extensively, but it looks >>>>>>>promising. We just have to make sure that it fulfills all our needs >>>>>>>completely and won't cause any problems down the road. Also, we have >>>>>>>to be able to support it on the off chance that the current developers >>>>>>>drop the project. >>>>>>> >>>>>>>My one worry is possible performance penalties. I think we should >>>>>>>check how much overhead Propel requires. >>>>>>> >>>>>>>Most importantly: I want to see GL2 get moving really soon. So a >>>>>>>decision on this has to happen soon. Can we get enough research done >>>>>>>on this topic that we're not causing more delays? >>>>>>> >>>>>>>I'll spend some more time reading the Propel docs. If nothing else the >>>>>>>idea sounds pretty interesting. >>>>>>> >>>>>>>-Vinny >>>>>>> >>>>>>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Ok, I think I sent this link here, but the more I read what I see, the >>>>>>>>more I like it. Please take some time to read about Propel: >>>>>>>> >>>>>>>>http://propel.phpdb.org >>>>>>>> >>>>>>>>And read the user guide: >>>>>>>> >>>>>>>>http://propel.phpdb.org/docs/user_guide/ >>>>>>>> >>>>>>>>The long and short of it is this. We could implement Data Acces Objects >>>>>>>>that our code uses to interact with the database. DAO is a good idea no >>>>>>>>matter what DB abstraction layer we use and regardless if we use a tool >>>>>>>>like Propel. Essentially it hides the data access specifics from the >>>>>>>>developers. Instead developers will call simple methods on the data >>>>>>>>access objects and let the DAO layer do the grunt work. >>>>>>>> >>>>>>>>We could essentially use DAO to wrap the use of Propel for data acess. >>>>>>>> >>>>>>>>That said there are some pros and cons: >>>>>>>> >>>>>>>>Pros: >>>>>>>>1) Clean API, developers no longer have to write SQL except in really >>>>>>>>rare instances. >>>>>>>>2) Object oriented...right in line with GL2 >>>>>>>>3) Database changes are easier, now developers don't have to find all >>>>>>>>SQL effected by a database change. We simply change things at the >>>>>>>>Propel level (wrapped by DAO), modify our HTML templates and we are off >>>>>>>>to the race. >>>>>>>> >>>>>>>>Cons: >>>>>>>>1) It is conceptionally more complicated. Requires some ramp up. >>>>>>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even >>>>>>>>if you wanted to). >>>>>>>>3) It's in Beta. >>>>>>>> >>>>>>>>I think this tool could really save a ton of time. Please give this a >>>>>>>>gander and try using it against a very simply table and let me know your >>>>>>>>thoughts. >>>>>>>> >>>>>>>>--Tony >>>>>>>>_______________________________________________ >>>>>>>>geeklog-devel mailing list >>>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>_______________________________________________ >>>>>>>geeklog-devel mailing list >>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>> >>>>>>>_______________________________________________ >>>>>>>geeklog-devel mailing list >>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>geeklog-devel mailing list >>>>>>geeklog-devel at lists.geeklog.net >>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Mon Aug 2 14:55:57 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 2 Aug 2004 14:55:57 -0400 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <410E8D35.4090508@tonybibbs.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> <8319e2d604080209552b70ebd5@mail.gmail.com> <410E8882.1080801@tonybibbs.com> <8319e2d604080211318f364e@mail.gmail.com> <410E8D35.4090508@tonybibbs.com> Message-ID: <8319e2d6040802115559dd5fce@mail.gmail.com> We should put together a list of what Propel needs in order for us to use it to see if our requirements are insurmountable. >From there, our options: 1. Ask propel folks if they can get it done, and if so how long it will take. 2. Do it ourselves In any case, I think at least a couple of us should install a try out Propel to see if all this work is worth it in any case. Tony, have you done this already? -Vinny On Mon, 02 Aug 2004 13:51:33 -0500, Tony Bibbs wrote: > Hrm, sticky situation. I guess we could try and get a hold of the > authors of this XSL stuff and see if they have any timelines for updates > to support other libraries. > > It would have been nice if the Propel folks would have added optional > support for the XSL support in PEAR. > > --Tony > > > > Vincent Furia wrote: > > >>From php.net: > > > >http://us2.php.net/xslt > > This PHP extension provides a processor independent API to XSLT > >transformations. Currently this extension only supports the Sablotron > >library from the Ginger Alliance. Support is planned for other > >libraries, such as the Xalan library or the libxslt library. > > > >My reading of this is only Sablotron is supported, not libxslt. > > > >-Vinny > > > > > >On Mon, 02 Aug 2004 13:31:30 -0500, Tony Bibbs wrote: > > > > > >>On linux it is libxslt I'm guessing. Yes, I already have it. However, > >>I have compiled PHP and provided neither the --with-xsl nor the > >>--without-xsl and the xsl related functions listed in the PHP manual > >>don't work. My guess is this is because the XSL support is still listed > >>as 'experimental' (as is the SOAP support). We should follow-up with > >>the PHP folks to see if they plan on including it as you described (i.e. > >>only if the libraries are already installed) once they are deemed > >>'stable'. > >> > >>Also, it's probaby worth noting that this would all work drastically > >>different in the case of windows. How, I'm not sure but since they > >>typcially don't install from source, they most likely will have > >>additional steps. > >> > >> > >> > >>--Tony > >> > >>Vincent Furia wrote: > >> > >> > >> > >>>I just looked in PHP 5's configure file. By default, XSLT is included > >>>if the supporting libraries are available on the host operating > >>>system. Is XSLT included with most linux distributions? What about > >>>Windows? Do standard binary installs of PHP 5 on Windows include > >>>XSLT? > >>> > >>>-Vinny > >>> > >>>On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: > >>> > >>> > >>> > >>> > >>>>Good question. I know the new XML support in PHP5 is included by > >>>>default. I'd have to search the manual to see if it enabled by > >>>>default. If it is, let's plan on using it. If not, I think this is > >>>>probably a deal killer. > >>>> > >>>>--Tony > >>>> > >>>> > >>>> > >>>>Vincent Furia wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I just noticed this about propel (pre-installation requirements): > >>>>> > >>>>># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable > >>>>>php_xsl.dll on Windows) > >>>>> > >>>>>Is XSLT a commonly supported item? Can we depend on it being compiled > >>>>>in on most PHP5 installations at ISPs? > >>>>> > >>>>>-Vinny > >>>>> > >>>>> > >>>>>On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Well, as far as other DB connections go, that is up to the coder, > >>>>>>obviously. GL2 should only worry about talking to the GL2 database so > >>>>>>if you want to access another database you should, without much hassle, > >>>>>>be able to open connections using the Creole DB layer that Propel uses: > >>>>>> > >>>>>>http://creole.phpdb.org/wiki/ > >>>>>> > >>>>>>Obviously you can still do your own with PEAR::DB or raw MySQL in your > >>>>>>code. The DAO layer simply provides a slick way to prevent the > >>>>>>developer from issuing raw SQL in the code...sometimes that can't be > >>>>>>avoided and I'm sure there is probably way to issue raw SQL in unique > >>>>>>scenarios (I need to verify that). > >>>>>> > >>>>>>--Tony > >>>>>> > >>>>>> > >>>>>> > >>>>>>Blaine Lang wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>It does look interesting and like many new libraries or models, it may be > >>>>>>>able to improve code readability, reduce code size, and improve > >>>>>>>re-useability but I do wonder if > >>>>>>>1) There are any SQL usage restrictions or more complex SQL queries that > >>>>>>>will not work. > >>>>>>>2) Will you still be able to use another DB access method and direct mysql_ > >>>>>>>calls using PHP > >>>>>>>3) Making GL2 too complex to understand for developers will effect it's > >>>>>>>support > >>>>>>> > >>>>>>>I have had reason on several occasions to need to access another mysql > >>>>>>>database when doing application integration. I just used the direct php > >>>>>>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x > >>>>>>>does not support this. We should consider this need in GL2 > >>>>>>> > >>>>>>>Blaine > >>>>>>>----- Original Message ----- > >>>>>>>From: "Vincent Furia" > >>>>>>>To: > >>>>>>>Sent: Saturday, July 31, 2004 11:17 PM > >>>>>>>Subject: Re: [geeklog-devel] Is this rocking the boat? > >>>>>>> > >>>>>>> > >>>>>>>I haven't had enough time to read up on this extensively, but it looks > >>>>>>>promising. We just have to make sure that it fulfills all our needs > >>>>>>>completely and won't cause any problems down the road. Also, we have > >>>>>>>to be able to support it on the off chance that the current developers > >>>>>>>drop the project. > >>>>>>> > >>>>>>>My one worry is possible performance penalties. I think we should > >>>>>>>check how much overhead Propel requires. > >>>>>>> > >>>>>>>Most importantly: I want to see GL2 get moving really soon. So a > >>>>>>>decision on this has to happen soon. Can we get enough research done > >>>>>>>on this topic that we're not causing more delays? > >>>>>>> > >>>>>>>I'll spend some more time reading the Propel docs. If nothing else the > >>>>>>>idea sounds pretty interesting. > >>>>>>> > >>>>>>>-Vinny > >>>>>>> > >>>>>>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Ok, I think I sent this link here, but the more I read what I see, the > >>>>>>>>more I like it. Please take some time to read about Propel: > >>>>>>>> > >>>>>>>>http://propel.phpdb.org > >>>>>>>> > >>>>>>>>And read the user guide: > >>>>>>>> > >>>>>>>>http://propel.phpdb.org/docs/user_guide/ > >>>>>>>> > >>>>>>>>The long and short of it is this. We could implement Data Acces Objects > >>>>>>>>that our code uses to interact with the database. DAO is a good idea no > >>>>>>>>matter what DB abstraction layer we use and regardless if we use a tool > >>>>>>>>like Propel. Essentially it hides the data access specifics from the > >>>>>>>>developers. Instead developers will call simple methods on the data > >>>>>>>>access objects and let the DAO layer do the grunt work. > >>>>>>>> > >>>>>>>>We could essentially use DAO to wrap the use of Propel for data acess. > >>>>>>>> > >>>>>>>>That said there are some pros and cons: > >>>>>>>> > >>>>>>>>Pros: > >>>>>>>>1) Clean API, developers no longer have to write SQL except in really > >>>>>>>>rare instances. > >>>>>>>>2) Object oriented...right in line with GL2 > >>>>>>>>3) Database changes are easier, now developers don't have to find all > >>>>>>>>SQL effected by a database change. We simply change things at the > >>>>>>>>Propel level (wrapped by DAO), modify our HTML templates and we are off > >>>>>>>>to the race. > >>>>>>>> > >>>>>>>>Cons: > >>>>>>>>1) It is conceptionally more complicated. Requires some ramp up. > >>>>>>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even > >>>>>>>>if you wanted to). > >>>>>>>>3) It's in Beta. > >>>>>>>> > >>>>>>>>I think this tool could really save a ton of time. Please give this a > >>>>>>>>gander and try using it against a very simply table and let me know your > >>>>>>>>thoughts. > >>>>>>>> > >>>>>>>>--Tony > >>>>>>>>_______________________________________________ > >>>>>>>>geeklog-devel mailing list > >>>>>>>>geeklog-devel at lists.geeklog.net > >>>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>geeklog-devel mailing list > >>>>>>>geeklog-devel at lists.geeklog.net > >>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>geeklog-devel mailing list > >>>>>>>geeklog-devel at lists.geeklog.net > >>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>_______________________________________________ > >>>>>>geeklog-devel mailing list > >>>>>>geeklog-devel at lists.geeklog.net > >>>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>_______________________________________________ > >>>>>geeklog-devel mailing list > >>>>>geeklog-devel at lists.geeklog.net > >>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Mon Aug 2 15:20:25 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 02 Aug 2004 14:20:25 -0500 Subject: [geeklog-devel] Is this rocking the boat? In-Reply-To: <8319e2d6040802115559dd5fce@mail.gmail.com> References: <410ABFD2.1070801@tonybibbs.com> <8319e2d604073120177a01fc81@mail.gmail.com> <002301c477d4$7374e7f0$650a10ac@XPBL2> <410E4BEF.8010809@tonybibbs.com> <8319e2d60408020901ff948ac@mail.gmail.com> <410E6A82.4050205@tonybibbs.com> <8319e2d604080209552b70ebd5@mail.gmail.com> <410E8882.1080801@tonybibbs.com> <8319e2d604080211318f364e@mail.gmail.com> <410E8D35.4090508@tonybibbs.com> <8319e2d6040802115559dd5fce@mail.gmail.com> Message-ID: <410E93F9.207@tonybibbs.com> Nope, not yet. It's on my to-do for this week. FWIW, we are using tools like this both in our .NET and Java environments and they are really slick. My next exercise is to hook up some more tables with parent/child relationsip and another with a recursive realtionship and see how it works. --Tony Vincent Furia wrote: >We should put together a list of what Propel needs in order for us to >use it to see if our requirements are insurmountable. > >>From there, our options: >1. Ask propel folks if they can get it done, and if so how long it will take. >2. Do it ourselves > >In any case, I think at least a couple of us should install a try out >Propel to see if all this work is worth it in any case. Tony, have >you done this already? > >-Vinny > >On Mon, 02 Aug 2004 13:51:33 -0500, Tony Bibbs wrote: > > >>Hrm, sticky situation. I guess we could try and get a hold of the >>authors of this XSL stuff and see if they have any timelines for updates >>to support other libraries. >> >>It would have been nice if the Propel folks would have added optional >>support for the XSL support in PEAR. >> >>--Tony >> >> >> >>Vincent Furia wrote: >> >> >> >>>>From php.net: >>> >>>http://us2.php.net/xslt >>>This PHP extension provides a processor independent API to XSLT >>>transformations. Currently this extension only supports the Sablotron >>>library from the Ginger Alliance. Support is planned for other >>>libraries, such as the Xalan library or the libxslt library. >>> >>>My reading of this is only Sablotron is supported, not libxslt. >>> >>>-Vinny >>> >>> >>>On Mon, 02 Aug 2004 13:31:30 -0500, Tony Bibbs wrote: >>> >>> >>> >>> >>>>On linux it is libxslt I'm guessing. Yes, I already have it. However, >>>>I have compiled PHP and provided neither the --with-xsl nor the >>>>--without-xsl and the xsl related functions listed in the PHP manual >>>>don't work. My guess is this is because the XSL support is still listed >>>>as 'experimental' (as is the SOAP support). We should follow-up with >>>>the PHP folks to see if they plan on including it as you described (i.e. >>>>only if the libraries are already installed) once they are deemed >>>>'stable'. >>>> >>>>Also, it's probaby worth noting that this would all work drastically >>>>different in the case of windows. How, I'm not sure but since they >>>>typcially don't install from source, they most likely will have >>>>additional steps. >>>> >>>> >>>> >>>>--Tony >>>> >>>>Vincent Furia wrote: >>>> >>>> >>>> >>>> >>>> >>>>>I just looked in PHP 5's configure file. By default, XSLT is included >>>>>if the supporting libraries are available on the host operating >>>>>system. Is XSLT included with most linux distributions? What about >>>>>Windows? Do standard binary installs of PHP 5 on Windows include >>>>>XSLT? >>>>> >>>>>-Vinny >>>>> >>>>>On Mon, 02 Aug 2004 11:23:30 -0500, Tony Bibbs wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Good question. I know the new XML support in PHP5 is included by >>>>>>default. I'd have to search the manual to see if it enabled by >>>>>>default. If it is, let's plan on using it. If not, I think this is >>>>>>probably a deal killer. >>>>>> >>>>>>--Tony >>>>>> >>>>>> >>>>>> >>>>>>Vincent Furia wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I just noticed this about propel (pre-installation requirements): >>>>>>> >>>>>>># PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable >>>>>>>php_xsl.dll on Windows) >>>>>>> >>>>>>>Is XSLT a commonly supported item? Can we depend on it being compiled >>>>>>>in on most PHP5 installations at ISPs? >>>>>>> >>>>>>>-Vinny >>>>>>> >>>>>>> >>>>>>>On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Well, as far as other DB connections go, that is up to the coder, >>>>>>>>obviously. GL2 should only worry about talking to the GL2 database so >>>>>>>>if you want to access another database you should, without much hassle, >>>>>>>>be able to open connections using the Creole DB layer that Propel uses: >>>>>>>> >>>>>>>>http://creole.phpdb.org/wiki/ >>>>>>>> >>>>>>>>Obviously you can still do your own with PEAR::DB or raw MySQL in your >>>>>>>>code. The DAO layer simply provides a slick way to prevent the >>>>>>>>developer from issuing raw SQL in the code...sometimes that can't be >>>>>>>>avoided and I'm sure there is probably way to issue raw SQL in unique >>>>>>>>scenarios (I need to verify that). >>>>>>>> >>>>>>>>--Tony >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Blaine Lang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>It does look interesting and like many new libraries or models, it may be >>>>>>>>>able to improve code readability, reduce code size, and improve >>>>>>>>>re-useability but I do wonder if >>>>>>>>>1) There are any SQL usage restrictions or more complex SQL queries that >>>>>>>>>will not work. >>>>>>>>>2) Will you still be able to use another DB access method and direct mysql_ >>>>>>>>>calls using PHP >>>>>>>>>3) Making GL2 too complex to understand for developers will effect it's >>>>>>>>>support >>>>>>>>> >>>>>>>>>I have had reason on several occasions to need to access another mysql >>>>>>>>>database when doing application integration. I just used the direct php >>>>>>>>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x >>>>>>>>>does not support this. We should consider this need in GL2 >>>>>>>>> >>>>>>>>>Blaine >>>>>>>>>----- Original Message ----- >>>>>>>>>From: "Vincent Furia" >>>>>>>>>To: >>>>>>>>>Sent: Saturday, July 31, 2004 11:17 PM >>>>>>>>>Subject: Re: [geeklog-devel] Is this rocking the boat? >>>>>>>>> >>>>>>>>> >>>>>>>>>I haven't had enough time to read up on this extensively, but it looks >>>>>>>>>promising. We just have to make sure that it fulfills all our needs >>>>>>>>>completely and won't cause any problems down the road. Also, we have >>>>>>>>>to be able to support it on the off chance that the current developers >>>>>>>>>drop the project. >>>>>>>>> >>>>>>>>>My one worry is possible performance penalties. I think we should >>>>>>>>>check how much overhead Propel requires. >>>>>>>>> >>>>>>>>>Most importantly: I want to see GL2 get moving really soon. So a >>>>>>>>>decision on this has to happen soon. Can we get enough research done >>>>>>>>>on this topic that we're not causing more delays? >>>>>>>>> >>>>>>>>>I'll spend some more time reading the Propel docs. If nothing else the >>>>>>>>>idea sounds pretty interesting. >>>>>>>>> >>>>>>>>>-Vinny >>>>>>>>> >>>>>>>>>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Ok, I think I sent this link here, but the more I read what I see, the >>>>>>>>>>more I like it. Please take some time to read about Propel: >>>>>>>>>> >>>>>>>>>>http://propel.phpdb.org >>>>>>>>>> >>>>>>>>>>And read the user guide: >>>>>>>>>> >>>>>>>>>>http://propel.phpdb.org/docs/user_guide/ >>>>>>>>>> >>>>>>>>>>The long and short of it is this. We could implement Data Acces Objects >>>>>>>>>>that our code uses to interact with the database. DAO is a good idea no >>>>>>>>>>matter what DB abstraction layer we use and regardless if we use a tool >>>>>>>>>>like Propel. Essentially it hides the data access specifics from the >>>>>>>>>>developers. Instead developers will call simple methods on the data >>>>>>>>>>access objects and let the DAO layer do the grunt work. >>>>>>>>>> >>>>>>>>>>We could essentially use DAO to wrap the use of Propel for data acess. >>>>>>>>>> >>>>>>>>>>That said there are some pros and cons: >>>>>>>>>> >>>>>>>>>>Pros: >>>>>>>>>>1) Clean API, developers no longer have to write SQL except in really >>>>>>>>>>rare instances. >>>>>>>>>>2) Object oriented...right in line with GL2 >>>>>>>>>>3) Database changes are easier, now developers don't have to find all >>>>>>>>>>SQL effected by a database change. We simply change things at the >>>>>>>>>>Propel level (wrapped by DAO), modify our HTML templates and we are off >>>>>>>>>>to the race. >>>>>>>>>> >>>>>>>>>>Cons: >>>>>>>>>>1) It is conceptionally more complicated. Requires some ramp up. >>>>>>>>>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even >>>>>>>>>>if you wanted to). >>>>>>>>>>3) It's in Beta. >>>>>>>>>> >>>>>>>>>>I think this tool could really save a ton of time. Please give this a >>>>>>>>>>gander and try using it against a very simply table and let me know your >>>>>>>>>>thoughts. >>>>>>>>>> >>>>>>>>>>--Tony >>>>>>>>>>_______________________________________________ >>>>>>>>>>geeklog-devel mailing list >>>>>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>geeklog-devel mailing list >>>>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>geeklog-devel mailing list >>>>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>geeklog-devel mailing list >>>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>_______________________________________________ >>>>>>>geeklog-devel mailing list >>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>geeklog-devel mailing list >>>>>>geeklog-devel at lists.geeklog.net >>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From geeklog at langfamily.ca Tue Aug 3 20:41:57 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Tue, 3 Aug 2004 20:41:57 -0400 Subject: [geeklog-devel] PHP Sessions and PEAR Class Message-ID: <003501c479bb$d96d22f0$650a10ac@XPBL2> We had a IRC discussion today and have agreed to add support for PHP SESSIONS into GL 1.3.10 (current CVS) As sugggested, I am looking at using PEAR class HTTP_Sessions v0.4 and have a few questions for the group. I've just reviewed the CLASS code and have these questions and observations 1) There will likely be a need to add a few new $_CONF options, specifically: - Mode: Option to use DB or Session files - Session_name: Default - Expiretime: Time for session to be active - Idletime: Possibly needed 2: What is the difference between Expire Time and Idle Time ? 3. What are the function methods for localVariables used for - what beneft ? ->setLocal(), ->getLocal(), ->localName() 4. I am thinking the only time we need to use session_destroy is upon logout. Blaine -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at haun-online.de Wed Aug 4 14:56:55 2004 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 4 Aug 2004 20:56:55 +0200 Subject: [geeklog-devel] PHP Sessions and PEAR Class In-Reply-To: <003501c479bb$d96d22f0$650a10ac@XPBL2> References: <003501c479bb$d96d22f0$650a10ac@XPBL2> Message-ID: <20040804195655.12126@smtp.haun-online.de> Guys, >We had a IRC discussion today and have agreed to add support for PHP >SESSIONS into GL 1.3.10 (current CVS) What was originally suggested sounded like a harmless little addition. With all these options of the HTTP_Sessions class, I'm beginning to wonder if it wouldn't be better to hold this back for the next release after 1.3.10 ... bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From dirk at haun-online.de Wed Aug 4 15:02:20 2004 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 4 Aug 2004 21:02:20 +0200 Subject: [geeklog-devel] 1.3.10 to do list In-Reply-To: <8319e2d604072710177f7055cb@mail.gmail.com> References: <8319e2d604072710177f7055cb@mail.gmail.com> Message-ID: <20040804200220.6902@smtp.haun-online.de> Coming back to this: >We should update the minimum requirements for Geeklog as well. Since >we've started using $_REQUEST in the core code in several places we'll >need to require PHP 4.1.0 or higher (at a minimum). Only pdfgenerator.php, comment.php and some comment-related code in lib- common.php seem to use $_REQUEST. How much work would it be to convert that code to using $HTTP_POST_VARS and $HTTP_GET_VARS? We have to move away from the $HTTP_xxx_VARS arrays eventually, as they seem to be disabled by default in PHP 5.0.0, but can we make one more release with the current requirements (which are PHP 4.0.4) and then convert all of it to $_POST, $_GET, and $_REQUEST for the next release (and, consequently, raise the requirements to PHP 4.1.0)? bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From vfuria at gmail.com Wed Aug 4 15:14:03 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 4 Aug 2004 15:14:03 -0400 Subject: [geeklog-devel] PHP Sessions and PEAR Class In-Reply-To: <20040804195655.12126@smtp.haun-online.de> References: <003501c479bb$d96d22f0$650a10ac@XPBL2> <20040804195655.12126@smtp.haun-online.de> Message-ID: <8319e2d604080412144c69bfb4@mail.gmail.com> I agree. If we push it back we can plan things out a bit better and maybe eliminate some of those other cookies we have... Dirk, maybe you should call out "feature freeze" and just spend the next two weeks squashing bugs in what we have thus far? -Vinny On Wed, 4 Aug 2004 20:56:55 +0200, Dirk Haun wrote: > Guys, > > >We had a IRC discussion today and have agreed to add support for PHP > >SESSIONS into GL 1.3.10 (current CVS) > > What was originally suggested sounded like a harmless little addition. > With all these options of the HTTP_Sessions class, I'm beginning to > wonder if it wouldn't be better to hold this back for the next release > after 1.3.10 ... > > bye, Dirk > > -- > http://www.haun-online.de/ > http://mypod.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From geeklog at langfamily.ca Wed Aug 4 15:17:32 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 4 Aug 2004 15:17:32 -0400 Subject: [geeklog-devel] PHP Sessions and PEAR Class References: <003501c479bb$d96d22f0$650a10ac@XPBL2> <20040804195655.12126@smtp.haun-online.de> Message-ID: <020601c47a57$b10a6b50$650a10ac@XPBL2> There actually is not that much that has to be added. I added 3 lines. I think it makes sense to use $_CONF to set these defines for the few that may want to change them. The defaults will be fine for most cases. I'd like to see this added as I can use this now in my plugins. We can then explore how we want to use it for the Core GL but at least the few lines required to enable it are there. I'd add the SESSIONS destroy on logout as well. My other questions were about the CLASS itself and I was thinking Tony or Vince had some insights. Blaine ----- Original Message ----- From: "Dirk Haun" To: Sent: Wednesday, August 04, 2004 2:56 PM Subject: Re: [geeklog-devel] PHP Sessions and PEAR Class Guys, >We had a IRC discussion today and have agreed to add support for PHP >SESSIONS into GL 1.3.10 (current CVS) What was originally suggested sounded like a harmless little addition. With all these options of the HTTP_Sessions class, I'm beginning to wonder if it wouldn't be better to hold this back for the next release after 1.3.10 ... bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From dirk at haun-online.de Wed Aug 4 16:56:01 2004 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 4 Aug 2004 22:56:01 +0200 Subject: [geeklog-devel] PHP Sessions and PEAR Class In-Reply-To: <8319e2d604080412144c69bfb4@mail.gmail.com> References: <8319e2d604080412144c69bfb4@mail.gmail.com> Message-ID: <20040804215601.16138@smtp.haun-online.de> Vinny, >I agree. If we push it back we can plan things out a bit better and >maybe eliminate some of those other cookies we have... Yeah, I've always had the feeling (and got the occasional complaint) that we're using too many cookies. >Dirk, maybe you should call out "feature freeze" and just spend the >next two weeks squashing bugs in what we have thus far? We need one or two new features for the integration of the SpamX plugin, and I don't want to rule out the occasional minor addition (as long as it doesn't break anything or require too many changes), but in general bugfixes are currently the #1 priority. bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From geeklog at langfamily.ca Wed Aug 4 17:13:44 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 4 Aug 2004 17:13:44 -0400 Subject: [geeklog-devel] PHP Sessions and PEAR Class References: <8319e2d604080412144c69bfb4@mail.gmail.com> <20040804215601.16138@smtp.haun-online.de> Message-ID: <028701c47a67$ed0c8f60$650a10ac@XPBL2> Vinny Wrote: I agree. If we push it back we can plan things out a bit better and maybe eliminate some of those other cookies we have... Dirk wrote Yeah, I've always had the feeling (and got the occasional complaint) that we're using too many cookies. I'm not sure we can eliminate these cookies since SESSIONS probally will only be resident on the server (if files are used) for 15min or so and if we use the DB for SESSIONS would we not be removing them as well after some configured time interval. Adding suport for SESSIONS should not be complicated to add to GL and it would be good to get some exposure and testing so that we can tweak it's usage and determine how best to use SESSIONS in our GL functions. ----- Original Message ----- From: "Dirk Haun" To: Sent: Wednesday, August 04, 2004 4:56 PM Subject: Re: [geeklog-devel] PHP Sessions and PEAR Class Vinny, >I agree. If we push it back we can plan things out a bit better and >maybe eliminate some of those other cookies we have... Yeah, I've always had the feeling (and got the occasional complaint) that we're using too many cookies. >Dirk, maybe you should call out "feature freeze" and just spend the >next two weeks squashing bugs in what we have thus far? We need one or two new features for the integration of the SpamX plugin, and I don't want to rule out the occasional minor addition (as long as it doesn't break anything or require too many changes), but in general bugfixes are currently the #1 priority. bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Wed Aug 4 17:49:25 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 04 Aug 2004 16:49:25 -0500 Subject: [geeklog-devel] PHP Sessions and PEAR Class In-Reply-To: <028701c47a67$ed0c8f60$650a10ac@XPBL2> References: <8319e2d604080412144c69bfb4@mail.gmail.com> <20040804215601.16138@smtp.haun-online.de> <028701c47a67$ed0c8f60$650a10ac@XPBL2> Message-ID: <411159E5.5000407@tonybibbs.com> Sessions are session. Thus how long a session lives either using files or the DB is up to the coder. It sounds like you thought the TTL was different for both and they are, in fact the same. Just a point of clarity. --Tony Blaine Lang wrote: >Vinny Wrote: I agree. If we push it back we can plan things out a bit better >and maybe eliminate some of those other cookies we have... >Dirk wrote Yeah, I've always had the feeling (and got the occasional >complaint) that we're using too many cookies. > >I'm not sure we can eliminate these cookies since SESSIONS probally will >only be resident on the server (if files are used) for 15min or so and if we >use the DB for SESSIONS would we not be removing them as well after some >configured time interval. > >Adding suport for SESSIONS should not be complicated to add to GL and it >would be good to get some exposure and testing so that we can tweak it's >usage and determine how best to use SESSIONS in our GL functions. > >----- Original Message ----- >From: "Dirk Haun" >To: >Sent: Wednesday, August 04, 2004 4:56 PM >Subject: Re: [geeklog-devel] PHP Sessions and PEAR Class > > >Vinny, > > > >>I agree. If we push it back we can plan things out a bit better and >>maybe eliminate some of those other cookies we have... >> >> > >Yeah, I've always had the feeling (and got the occasional complaint) that >we're using too many cookies. > > > > >>Dirk, maybe you should call out "feature freeze" and just spend the >>next two weeks squashing bugs in what we have thus far? >> >> > >We need one or two new features for the integration of the SpamX plugin, >and I don't want to rule out the occasional minor addition (as long as it >doesn't break anything or require too many changes), but in general >bugfixes are currently the #1 priority. > >bye, Dirk > > > > From geeklog at langfamily.ca Wed Aug 4 18:49:59 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 4 Aug 2004 18:49:59 -0400 Subject: [geeklog-devel] PHP Sessions and PEAR Class References: <8319e2d604080412144c69bfb4@mail.gmail.com> <20040804215601.16138@smtp.haun-online.de> <028701c47a67$ed0c8f60$650a10ac@XPBL2> <411159E5.5000407@tonybibbs.com> Message-ID: <02d101c47a75$5edab3d0$650a10ac@XPBL2> Tony wrote: > Sessions are session. Thus how long a session lives either using files or the DB is up to the coder. It sounds like you thought the TTL was different for both and they are, in fact the same. Nope - I knew that the location of storage had no effect. Thats not what I was referring to. I was stating that SESSIONS are not normally designed to be active as long as cookies and thus we may not find they can replace cookies. I was also stating that we may want to use $_CONF for some of the SESSION settings such as TTL. Tony, can you review my initial questions I'd like your input. I've just reviewed the CLASS code and have these questions and observations 1) There will likely be a need to add a few new $_CONF options, specifically: - Mode: Option to use DB or Session files - Session_name: Default - Expiretime: Time for session to be active - Idletime: Possibly needed 2: What is the difference between Expire Time and Idle Time ? 3. What are the function methods for localVariables used for - what beneft ? ->setLocal(), ->getLocal(), ->localName() 4. I am thinking the only time we need to use session_destroy is upon logout. ----- Original Message ----- From: "Tony Bibbs" To: Sent: Wednesday, August 04, 2004 5:49 PM Subject: Re: [geeklog-devel] PHP Sessions and PEAR Class Sessions are session. Thus how long a session lives either using files or the DB is up to the coder. It sounds like you thought the TTL was different for both and they are, in fact the same. Just a point of clarity. --Tony Blaine Lang wrote: >Vinny Wrote: I agree. If we push it back we can plan things out a bit better >and maybe eliminate some of those other cookies we have... >Dirk wrote Yeah, I've always had the feeling (and got the occasional >complaint) that we're using too many cookies. > >I'm not sure we can eliminate these cookies since SESSIONS probally will >only be resident on the server (if files are used) for 15min or so and if we >use the DB for SESSIONS would we not be removing them as well after some >configured time interval. > >Adding suport for SESSIONS should not be complicated to add to GL and it >would be good to get some exposure and testing so that we can tweak it's >usage and determine how best to use SESSIONS in our GL functions. > >----- Original Message ----- >From: "Dirk Haun" >To: >Sent: Wednesday, August 04, 2004 4:56 PM >Subject: Re: [geeklog-devel] PHP Sessions and PEAR Class > > >Vinny, > > > >>I agree. If we push it back we can plan things out a bit better and >>maybe eliminate some of those other cookies we have... >> >> > >Yeah, I've always had the feeling (and got the occasional complaint) that >we're using too many cookies. > > > > >>Dirk, maybe you should call out "feature freeze" and just spend the >>next two weeks squashing bugs in what we have thus far? >> >> > >We need one or two new features for the integration of the SpamX plugin, >and I don't want to rule out the occasional minor addition (as long as it >doesn't break anything or require too many changes), but in general >bugfixes are currently the #1 priority. > >bye, Dirk > > > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From vfuria at gmail.com Wed Aug 4 23:45:28 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 4 Aug 2004 23:45:28 -0400 Subject: [geeklog-devel] 1.3.10 to do list In-Reply-To: <20040804200220.6902@smtp.haun-online.de> References: <8319e2d604072710177f7055cb@mail.gmail.com> <20040804200220.6902@smtp.haun-online.de> Message-ID: <8319e2d604080420453290bba8@mail.gmail.com> For the record, instances of $_REQUEST in files: public_html/comment.php:11 public_html/lib-common.php:7 public_html/mail/index.php:3 public_html/pdfgenerator.php:13 system/classes/search.class.php:1 <--- I think this is just a comment I guess I can take care of comment.php if you really think this is necessary. Honestly I don't think this is that big a deal. Anyone using PHP < 4.1.0 is open to so many security holes we're probably doing them a favor... $_REQUEST makes things, much, much easier (at least in comment.php) because forms submitting input to the script have a mix of GET and POST variables (and often some variables are used both ways depending on from where they are called). -Vinny On Wed, 4 Aug 2004 21:02:20 +0200, Dirk Haun wrote: > Coming back to this: > > >We should update the minimum requirements for Geeklog as well. Since > >we've started using $_REQUEST in the core code in several places we'll > >need to require PHP 4.1.0 or higher (at a minimum). > > Only pdfgenerator.php, comment.php and some comment-related code in lib- > common.php seem to use $_REQUEST. > > How much work would it be to convert that code to using $HTTP_POST_VARS > and $HTTP_GET_VARS? > > We have to move away from the $HTTP_xxx_VARS arrays eventually, as they > seem to be disabled by default in PHP 5.0.0, but can we make one more > release with the current requirements (which are PHP 4.0.4) and then > convert all of it to $_POST, $_GET, and $_REQUEST for the next release > (and, consequently, raise the requirements to PHP 4.1.0)? > > > > bye, Dirk > > -- > http://www.haun-online.de/ > http://geeklog.info/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Thu Aug 5 15:05:02 2004 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 5 Aug 2004 21:05:02 +0200 Subject: [geeklog-devel] 1.3.10 to do list In-Reply-To: <8319e2d604080420453290bba8@mail.gmail.com> References: <8319e2d604080420453290bba8@mail.gmail.com> Message-ID: <20040805200502.16904@smtp.haun-online.de> >For the record, instances of $_REQUEST in files: > >public_html/mail/index.php:3 Hmm? What's that? Looks like a plugin ... >Honestly I don't think this is that big a deal. Anyone >using PHP < 4.1.0 is open to so many security holes we're probably >doing them a favor... Yeah, I guess it's kind of silly trying to be compatible with each and everything. Okay, we'll keep the $_REQUEST for now. If enough people complain during the release candidate phase, we can still change it then. bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From vfuria at gmail.com Thu Aug 5 15:26:44 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 5 Aug 2004 15:26:44 -0400 Subject: [geeklog-devel] 1.3.10 to do list In-Reply-To: <20040805200502.16904@smtp.haun-online.de> References: <8319e2d604080420453290bba8@mail.gmail.com> <20040805200502.16904@smtp.haun-online.de> Message-ID: <8319e2d6040805122626312e3b@mail.gmail.com> On Thu, 5 Aug 2004 21:05:02 +0200, Dirk Haun wrote: > >For the record, instances of $_REQUEST in files: > > > >public_html/mail/index.php:3 > > Hmm? What's that? Looks like a plugin ... > Ooops. Not even a plugin, just a script I'm messing around with. I thought I had culled all those out. -Vinny From dirk at haun-online.de Sat Aug 7 18:32:04 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 8 Aug 2004 00:32:04 +0200 Subject: [geeklog-devel] comment.php?mode=view Message-ID: <20040807233204.26993@smtp.haun-online.de> Vinny (et al.), now that we have the ability to link to individual comments, it would make sense when comment search results would link to the actual comment (using mode=view). However, when doing that, there's no way to get from that comment to the story that comment belongs to. The comment doesn't have a "Parent" link either. Any ideas? bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From dirk at haun-online.de Sun Aug 8 15:31:46 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 8 Aug 2004 21:31:46 +0200 Subject: [geeklog-devel] Problem with HTTP_Sessions Message-ID: <20040808203146.25988@smtp.haun-online.de> Blaine made the changes to use the HTTP_Sessions class in CVS now. It seems that class is not part of the standard PEAR install, though. So when people chose to use the PEAR classes installed on their server, they may not have that class there. Looks like we're in for another support nightmare :-( To recap, currently we're doing this: If $_CONF['have_pear'] = false, i.e. the user either doesn't have PEAR installed or chose to use the version we're supplying with Geeklog, we use ini_set to add our PEAR path (/path/to/geeklog/system/pear) to the system's include path. We have to do that since the PEAR classes only use relative paths for their includes. Problem: ini_set may not be allowed on some hosts. If $_CONF['have_pear'] = true, i.e. the user chose to use the PEAR version installed on the server, we don't use ini_set and rely on the include path being properly set on the server anyway. Problem: HTTP_Sessions is not part of the standard PEAR install and may not be available on the server. Comments, suggestions? Go back to plain PHP sessions? Drop them entirely? Other ideas? bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From tony at tonybibbs.com Sun Aug 8 19:41:28 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sun, 08 Aug 2004 18:41:28 -0500 Subject: [geeklog-devel] Problem with HTTP_Sessions In-Reply-To: <20040808203146.25988@smtp.haun-online.de> References: <20040808203146.25988@smtp.haun-online.de> Message-ID: <4116BA28.8010305@tonybibbs.com> Just add $_CONF['path_http_session']. Make it an absolute path and everybody can be happy. Include it in GL by default in /system --Tony Dirk Haun wrote: >Blaine made the changes to use the HTTP_Sessions class in CVS now. It >seems that class is not part of the standard PEAR install, though. So >when people chose to use the PEAR classes installed on their server, they >may not have that class there. > >Looks like we're in for another support nightmare :-( > > >To recap, currently we're doing this: > >If $_CONF['have_pear'] = false, i.e. the user either doesn't have PEAR >installed or chose to use the version we're supplying with Geeklog, we >use ini_set to add our PEAR path (/path/to/geeklog/system/pear) to the >system's include path. We have to do that since the PEAR classes only use >relative paths for their includes. > >Problem: ini_set may not be allowed on some hosts. > >If $_CONF['have_pear'] = true, i.e. the user chose to use the PEAR >version installed on the server, we don't use ini_set and rely on the >include path being properly set on the server anyway. > >Problem: HTTP_Sessions is not part of the standard PEAR install and may >not be available on the server. > >Comments, suggestions? Go back to plain PHP sessions? Drop them entirely? >Other ideas? > >bye, Dirk > > > > From vfuria at gmail.com Mon Aug 9 08:44:44 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 9 Aug 2004 08:44:44 -0400 Subject: [geeklog-devel] comment.php?mode=view In-Reply-To: <20040807233204.26993@smtp.haun-online.de> References: <20040807233204.26993@smtp.haun-online.de> Message-ID: <8319e2d604080905447fd23e59@mail.gmail.com> I'll look at adding something to the comment bar to link back to the original article (poll, plugin, ...). Perhaps only make it available if viewing comments from comment.php. I'm traveling this week, so I may not get to it until the weekend. -Vinny On Sun, 8 Aug 2004 00:32:04 +0200, Dirk Haun wrote: > Vinny (et al.), > > now that we have the ability to link to individual comments, it would > make sense when comment search results would link to the actual comment > (using mode=view). > > However, when doing that, there's no way to get from that comment to the > story that comment belongs to. The comment doesn't have a "Parent" link > either. > > Any ideas? > > bye, Dirk > > -- > http://www.haun-online.de/ > http://mypod.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Sun Aug 15 15:02:32 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 15 Aug 2004 21:02:32 +0200 Subject: [geeklog-devel] comment.php?mode=view In-Reply-To: <8319e2d604080905447fd23e59@mail.gmail.com> References: <8319e2d604080905447fd23e59@mail.gmail.com> Message-ID: <20040815200232.14293@smtp.haun-online.de> Vinny, >I'll look at adding something to the comment bar to link back to the >original article (poll, plugin, ...). Perhaps only make it available >if viewing comments from comment.php. Another thing I've noticed is that the 'delete' option is not displayed (for admins) in that mode. So while you're at it, could you fix that, too, please? This is especially important as the new "report abuse" option sends an email that uses a "mode=view" link. So it's necessary that the 'delete' option is there so that abusive comments can be deleted easily. bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From dirk at haun-online.de Mon Aug 16 09:16:11 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 16 Aug 2004 15:16:11 +0200 Subject: [geeklog-devel] Updated 1.3.10 to-do list Message-ID: <20040816141611.18371@smtp.haun-online.de> Okay, looks like we're down to these tasks: Tony: - fix pdf generator - integrate SpamX plugin Blaine: - fix archive option (delete images when article is deleted) Vinny: - add link back to the story for comments in 'view' mode - fix display of Admin options (delete, IP address lookup) in 'view' mode Dirk: - update documentation - update language files - add Professional theme to CVS Simon: - new logo Anything else? Can we get this done until, say, next weekend? Btw, I'll be pretty much offline Tuesday - Thursday, but will catch up with you on Friday. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From tony at tonybibbs.com Mon Aug 16 14:55:07 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 16 Aug 2004 13:55:07 -0500 Subject: [geeklog-devel] [Fwd: Iowa Outdoors Story Submissions] Message-ID: <4121030B.6000100@tonybibbs.com> FYI, there's a stripslashes missing apparently. -------- Original Message -------- Subject: Iowa Outdoors Story Submissions Date: Mon, 16 Aug 2004 14:00:28 -0500 From: Iowa Outdoors To: webmaster at iowaoutdoors.org Title: Shotgun barrel lenght Author: TotallyHooked Date: Monday, August 16 2004 @ 02:00 PM CDT Topic: Hunting What\'s your favorite shotgun barrel length, and why? Submissions ------------------------------ End of Message ------------------------------ From vfuria at gmail.com Mon Aug 16 16:37:02 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 16 Aug 2004 16:37:02 -0400 Subject: [geeklog-devel] Geeklog-1.3 CVS Message-ID: <8319e2d6040816133752b42473@mail.gmail.com> Anyone know what happened to the /docs directory. It doesn't appear to be in CVS right now?!? -Vinny From tony at tonybibbs.com Mon Aug 16 16:48:58 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 16 Aug 2004 15:48:58 -0500 Subject: [geeklog-devel] Geeklog-1.3 CVS In-Reply-To: <8319e2d6040816133752b42473@mail.gmail.com> References: <8319e2d6040816133752b42473@mail.gmail.com> Message-ID: <41211DBA.6030801@tonybibbs.com> It got moved. Dirk sent a note saying as much late last week. See here: http://cvs.geeklog.net/cvs.php/geeklog-1.3/public_html/docs?login=2&Horde=c4fca74f586d0574f51190446364ee91 --Tony Vincent Furia wrote: >Anyone know what happened to the /docs directory. It doesn't appear >to be in CVS right now?!? > >-Vinny >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dirk at haun-online.de Mon Aug 16 17:31:11 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 16 Aug 2004 23:31:11 +0200 Subject: [geeklog-devel] Re: [geeklog-cvs] geeklog-1.3/public_html lib-common.php,1.361,1.362 In-Reply-To: <20040816210955.8BAE9361ED@tonybibbs.com> References: <20040816210955.8BAE9361ED@tonybibbs.com> Message-ID: <20040816223111.18753@smtp.haun-online.de> >Modified Files: > lib-common.php [...] >! //require_once( '/path/to/geeklog/config.php' ); >! require_once( '/home/vmf/work/geeklog-1.3/config.php' ); Erm ... Vincent ... bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From vfuria at gmail.com Mon Aug 16 20:54:55 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 16 Aug 2004 20:54:55 -0400 Subject: [geeklog-devel] Re: [geeklog-cvs] geeklog-1.3/public_html lib-common.php,1.361,1.362 In-Reply-To: <20040816223111.18753@smtp.haun-online.de> References: <20040816210955.8BAE9361ED@tonybibbs.com> <20040816223111.18753@smtp.haun-online.de> Message-ID: <8319e2d604081617547e2f2146@mail.gmail.com> Sorry Mom... I won't do it again. Promise! -Vinny On Mon, 16 Aug 2004 23:31:11 +0200, Dirk Haun wrote: > >Modified Files: > > lib-common.php > [...] > >! //require_once( '/path/to/geeklog/config.php' ); > >! require_once( '/home/vmf/work/geeklog-1.3/config.php' ); > > Erm ... Vincent ... > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.macosx-faq.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Tue Aug 17 11:00:17 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 17 Aug 2004 10:00:17 -0500 Subject: [geeklog-devel] Zend Editor Message-ID: <41221D81.8040505@tonybibbs.com> I've tried, in vain, to get free professional edition copies of Zend Studio. The best they could offer was the academic discount of 25% off. That takes the $250 price tag down to $187. For what it is worth, my full trial version expired today and a few features got disabled. To my amazement, however, the debugger still works which...by itself is worth gold. That being said, I'd really encourage those who haven't tried it to give it a try. I've dumped my ActiveState license for Zend and I would have done so even if my employer wasn't buying us some licenses. The features that I have noticed that have been disabled is CVS integration and the introspection stuff which is handy but not terribly useful, IMHO. Anyway, let me know if anybody wants the full blown version at that price. --Tony From slord at marelina.com Tue Aug 17 21:55:32 2004 From: slord at marelina.com (Simon Lord) Date: Tue, 17 Aug 2004 21:55:32 -0400 Subject: [geeklog-devel] Javascript menu Message-ID: I was fortunate to come across the following script via a buddy. It has to be the smallest javascript code and css I've ever seen supporting a wickedly cool hierarchical menu system. I spent the day making new icons for it and totally rewriting the css so it looks better. If any genius here thinks they can tie it into the Topics block then please send me your hack. Ideally the topic name would be the main link with the story names being the items with the menu. I have a hardcoded version working here: http://www.karbonized.com/dmx/ Hopefully the file (9k) is attached below... -------------- next part -------------- A non-text attachment was scrubbed... Name: site-menu.zip Type: application/zip Size: 9660 bytes Desc: not available URL: -------------- next part -------------- Sincerely, Simon From geeklog at langfamily.ca Tue Aug 17 22:29:22 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Tue, 17 Aug 2004 22:29:22 -0400 Subject: [geeklog-devel] Zend Editor References: <41221D81.8040505@tonybibbs.com> Message-ID: <067e01c484cb$2c0eee20$650a10ac@XPBL2> Hi Tony, I too have never been overly impressed with the ActiveState IDE. I just found it too slow on my WinXP desktop and it's not a under-powered desktop. I also recently tried the ZendStudio and liked it but I keep coming back to my super fast editor that I love to use - EditPlus. I do like the integrated debugger but I also found it slow at times - no where as bad as Komodo. I just hate it when I'm typing and there is a delay. My trial expired before I had given it enough hour of testing. I know there are many benefits and it takes time to change your style and get used to a new devel environment. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Tuesday, August 17, 2004 11:00 AM Subject: [geeklog-devel] Zend Editor I've tried, in vain, to get free professional edition copies of Zend Studio. The best they could offer was the academic discount of 25% off. That takes the $250 price tag down to $187. For what it is worth, my full trial version expired today and a few features got disabled. To my amazement, however, the debugger still works which...by itself is worth gold. That being said, I'd really encourage those who haven't tried it to give it a try. I've dumped my ActiveState license for Zend and I would have done so even if my employer wasn't buying us some licenses. The features that I have noticed that have been disabled is CVS integration and the introspection stuff which is handy but not terribly useful, IMHO. Anyway, let me know if anybody wants the full blown version at that price. --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From dwight at trumbower.com Tue Aug 17 22:57:42 2004 From: dwight at trumbower.com (Dwight Trumbower) Date: Tue, 17 Aug 2004 21:57:42 -0500 Subject: [geeklog-devel] Javascript menu In-Reply-To: References: Message-ID: <4122C5A6.10303@trumbower.com> Looks nice in IE, not so nice in Mozilla. Simon Lord wrote: > I was fortunate to come across the following script via a buddy. It has > to be the smallest javascript code and css I've ever seen supporting a > wickedly cool hierarchical menu system. > > I spent the day making new icons for it and totally rewriting the css so > it looks better. If any genius here thinks they can tie it into the > Topics block then please send me your hack. Ideally the topic name > would be the main link with the story names being the items with the > menu. I have a hardcoded version working here: > > http://www.karbonized.com/dmx/ > > Hopefully the file (9k) is attached below... > > > > > Sincerely, > Simon > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > avast! Antivirus : Inbound message clean. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: simon1.jpg Type: image/jpeg Size: 110245 bytes Desc: not available URL: From geeklog at langfamily.ca Tue Aug 17 23:03:20 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Tue, 17 Aug 2004 23:03:20 -0400 Subject: [geeklog-devel] Javascript menu References: <4122C5A6.10303@trumbower.com> Message-ID: <06a001c484cf$ea9d71a0$650a10ac@XPBL2> Hum .. this is what I see in IE. I see the same as Dwight in Firefox ----- Original Message ----- From: "Dwight Trumbower" To: Sent: Tuesday, August 17, 2004 10:57 PM Subject: Re: [geeklog-devel] Javascript menu Looks nice in IE, not so nice in Mozilla. Simon Lord wrote: > I was fortunate to come across the following script via a buddy. It has > to be the smallest javascript code and css I've ever seen supporting a > wickedly cool hierarchical menu system. > > I spent the day making new icons for it and totally rewriting the css so > it looks better. If any genius here thinks they can tie it into the > Topics block then please send me your hack. Ideally the topic name > would be the main link with the story names being the items with the > menu. I have a hardcoded version working here: > > http://www.karbonized.com/dmx/ > > Hopefully the file (9k) is attached below... > > > > > Sincerely, > Simon > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > avast! Antivirus : Inbound message clean. > > ---------------------------------------------------------------------------- ---- -------------- next part -------------- A non-text attachment was scrubbed... Name: dmx.jpg Type: image/jpeg Size: 88032 bytes Desc: not available URL: From slord at marelina.com Tue Aug 17 23:25:23 2004 From: slord at marelina.com (Simon Lord) Date: Tue, 17 Aug 2004 23:25:23 -0400 Subject: [geeklog-devel] Javascript menu In-Reply-To: <06a001c484cf$ea9d71a0$650a10ac@XPBL2> References: <4122C5A6.10303@trumbower.com> <06a001c484cf$ea9d71a0$650a10ac@XPBL2> Message-ID: <3D96CFBA-F0C6-11D8-A35E-003065C030F2@marelina.com> Yeah, I just noticed some of that crud also. It's uses some good css2 and some stuff appears to either not be compatible or not treated the same way across all the browsers. I'm trying to find some kind of zen balance across the browsers now. Crap. On Aug 17, 2004, at 11:03 PM, Blaine Lang wrote: > Hum .. this is what I see in IE. > I see the same as Dwight in Firefox > ----- Original Message ----- > From: "Dwight Trumbower" > To: > Sent: Tuesday, August 17, 2004 10:57 PM > Subject: Re: [geeklog-devel] Javascript menu > > > Looks nice in IE, not so nice in Mozilla. > > Simon Lord wrote: > >> I was fortunate to come across the following script via a buddy. It >> has >> to be the smallest javascript code and css I've ever seen supporting a >> wickedly cool hierarchical menu system. >> >> I spent the day making new icons for it and totally rewriting the css >> so >> it looks better. If any genius here thinks they can tie it into the >> Topics block then please send me your hack. Ideally the topic name >> would be the main link with the story names being the items with the >> menu. I have a hardcoded version working here: >> >> http://www.karbonized.com/dmx/ >> >> Hopefully the file (9k) is attached below... >> >> >> >> >> Sincerely, >> Simon >> >> ---------------------------------------------------------------------- >> -- >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> avast! Antivirus : Inbound message clean. >> >> > > > > > ----------------------------------------------------------------------- > ----- > ---- > > > > Sincerely, Simon From slord at marelina.com Wed Aug 18 10:39:13 2004 From: slord at marelina.com (Simon Lord) Date: Wed, 18 Aug 2004 10:39:13 -0400 Subject: [geeklog-devel] Javascript menu In-Reply-To: <3D96CFBA-F0C6-11D8-A35E-003065C030F2@marelina.com> References: <4122C5A6.10303@trumbower.com> <06a001c484cf$ea9d71a0$650a10ac@XPBL2> <3D96CFBA-F0C6-11D8-A35E-003065C030F2@marelina.com> Message-ID: <5FF385C4-F124-11D8-A35E-003065C030F2@marelina.com> Ok, I found the problem for the crud in my javascript menu. I think at issue is the following tag in css: display: block; ... in many browsers this appears to force a carriage return at each line making the space between each line look like double-spacing. Anyone know some kind of fix to prevent this apparent line break from happening? On Aug 17, 2004, at 11:25 PM, Simon Lord wrote: > Yeah, I just noticed some of that crud also. It's uses some good css2 > and some stuff appears to either not be compatible or not treated the > same way across all the browsers. > > I'm trying to find some kind of zen balance across the browsers now. > Crap. > > > > On Aug 17, 2004, at 11:03 PM, Blaine Lang wrote: > >> Hum .. this is what I see in IE. >> I see the same as Dwight in Firefox >> ----- Original Message ----- >> From: "Dwight Trumbower" >> To: >> Sent: Tuesday, August 17, 2004 10:57 PM >> Subject: Re: [geeklog-devel] Javascript menu >> >> >> Looks nice in IE, not so nice in Mozilla. >> >> Simon Lord wrote: >> >>> I was fortunate to come across the following script via a buddy. It >>> has >>> to be the smallest javascript code and css I've ever seen supporting >>> a >>> wickedly cool hierarchical menu system. >>> >>> I spent the day making new icons for it and totally rewriting the >>> css so >>> it looks better. If any genius here thinks they can tie it into the >>> Topics block then please send me your hack. Ideally the topic name >>> would be the main link with the story names being the items with the >>> menu. I have a hardcoded version working here: >>> >>> http://www.karbonized.com/dmx/ >>> >>> Hopefully the file (9k) is attached below... >>> >>> >>> >>> >>> Sincerely, >>> Simon >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> avast! Antivirus : Inbound message clean. >>> >>> >> >> >> >> >> ---------------------------------------------------------------------- >> ------ >> ---- >> >> >> >> > Sincerely, > Simon > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > Sincerely, Simon From slord at marelina.com Wed Aug 18 10:48:32 2004 From: slord at marelina.com (Simon Lord) Date: Wed, 18 Aug 2004 10:48:32 -0400 Subject: [geeklog-devel] Javascript menu In-Reply-To: <5FF385C4-F124-11D8-A35E-003065C030F2@marelina.com> References: <4122C5A6.10303@trumbower.com> <06a001c484cf$ea9d71a0$650a10ac@XPBL2> <3D96CFBA-F0C6-11D8-A35E-003065C030F2@marelina.com> <5FF385C4-F124-11D8-A35E-003065C030F2@marelina.com> Message-ID: Got it. display: block; by nature will cause a line break to appear whereas "display: run-in;" which is a new addition to css2 will prevent this line break effect from happening. It seems to look good in IE now. I'm still tweaking the css to eliminate some artifacts but it seems I'll be able to get it running smoothly shortly. On Aug 18, 2004, at 10:39 AM, Simon Lord wrote: > Ok, I found the problem for the crud in my javascript menu. I think > at issue is the following tag in css: > > display: block; > > ... in many browsers this appears to force a carriage return at each > line making the space between each line look like double-spacing. > > Anyone know some kind of fix to prevent this apparent line break from > happening? > > > > On Aug 17, 2004, at 11:25 PM, Simon Lord wrote: > >> Yeah, I just noticed some of that crud also. It's uses some good >> css2 and some stuff appears to either not be compatible or not >> treated the same way across all the browsers. >> >> I'm trying to find some kind of zen balance across the browsers now. >> Crap. >> >> >> >> On Aug 17, 2004, at 11:03 PM, Blaine Lang wrote: >> >>> Hum .. this is what I see in IE. >>> I see the same as Dwight in Firefox >>> ----- Original Message ----- >>> From: "Dwight Trumbower" >>> To: >>> Sent: Tuesday, August 17, 2004 10:57 PM >>> Subject: Re: [geeklog-devel] Javascript menu >>> >>> >>> Looks nice in IE, not so nice in Mozilla. >>> >>> Simon Lord wrote: >>> >>>> I was fortunate to come across the following script via a buddy. >>>> It has >>>> to be the smallest javascript code and css I've ever seen >>>> supporting a >>>> wickedly cool hierarchical menu system. >>>> >>>> I spent the day making new icons for it and totally rewriting the >>>> css so >>>> it looks better. If any genius here thinks they can tie it into the >>>> Topics block then please send me your hack. Ideally the topic name >>>> would be the main link with the story names being the items with the >>>> menu. I have a hardcoded version working here: >>>> >>>> http://www.karbonized.com/dmx/ >>>> >>>> Hopefully the file (9k) is attached below... >>>> >>>> >>>> >>>> >>>> Sincerely, >>>> Simon >>>> >>>> -------------------------------------------------------------------- >>>> ---- >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> ---- >>>> >>>> avast! Antivirus : Inbound message clean. >>>> >>>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> ------- >>> ---- >>> >>> >>> >>> >> Sincerely, >> Simon >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> > Sincerely, > Simon > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > Sincerely, Simon From tony at tonybibbs.com Wed Aug 18 10:59:34 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 18 Aug 2004 09:59:34 -0500 Subject: [geeklog-devel] Zend Editor In-Reply-To: <067e01c484cb$2c0eee20$650a10ac@XPBL2> References: <41221D81.8040505@tonybibbs.com> <067e01c484cb$2c0eee20$650a10ac@XPBL2> Message-ID: <41236ED6.7090806@tonybibbs.com> Yeah, this does become a coke vs pepsi sort of argument but you should try the new version compatible with PHP5. Granted I have a pretty hefty laptop but everything is quite snappy. Right click menus, debugging, code analyzer, etc all work faster than I could tolerate (which is good). IMHO, the debugger alone with the standard watches, breakpoints, call stack, etc is worth it. For me it is also a no brainer, we are getting professional copies here at work ;-) --Tony Blaine Lang wrote: >Hi Tony, > >I too have never been overly impressed with the ActiveState IDE. I just >found it too slow on my WinXP desktop and it's not a under-powered desktop. >I also recently tried the ZendStudio and liked it but I keep coming back to >my super fast editor that I love to use - EditPlus. I do like the >integrated debugger but I also found it slow at times - no where as bad as >Komodo. I just hate it when I'm typing and there is a delay. > >My trial expired before I had given it enough hour of testing. I know there >are many benefits and it takes time to change your style and get used to a >new devel environment. > >Blaine > >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Tuesday, August 17, 2004 11:00 AM >Subject: [geeklog-devel] Zend Editor > > >I've tried, in vain, to get free professional edition copies of Zend >Studio. The best they could offer was the academic discount of 25% >off. That takes the $250 price tag down to $187. For what it is >worth, my full trial version expired today and a few features got >disabled. To my amazement, however, the debugger still works which...by >itself is worth gold. > >That being said, I'd really encourage those who haven't tried it to give >it a try. I've dumped my ActiveState license for Zend and I would have >done so even if my employer wasn't buying us some licenses. The >features that I have noticed that have been disabled is CVS integration >and the introspection stuff which is handy but not terribly useful, IMHO. > >Anyway, let me know if anybody wants the full blown version at that price. > >--Tony >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From pyrox_pro at hotmail.com Wed Aug 18 12:08:43 2004 From: pyrox_pro at hotmail.com (Justin Carlson) Date: Wed, 18 Aug 2004 10:08:43 -0600 Subject: [geeklog-devel] Zend Editor References: <41221D81.8040505@tonybibbs.com> <067e01c484cb$2c0eee20$650a10ac@XPBL2> <41236ED6.7090806@tonybibbs.com> Message-ID: Yes, it's the only way he can get me off of Vim It's the first setup I've liked well enough to change my ways. - Justin ----- Original Message ----- From: "Tony Bibbs" To: Sent: Wednesday, August 18, 2004 8:59 AM Subject: Re: [geeklog-devel] Zend Editor > Yeah, this does become a coke vs pepsi sort of argument but you should > try the new version compatible with PHP5. Granted I have a pretty hefty > laptop but everything is quite snappy. Right click menus, debugging, > code analyzer, etc all work faster than I could tolerate (which is good). > > IMHO, the debugger alone with the standard watches, breakpoints, call > stack, etc is worth it. > > For me it is also a no brainer, we are getting professional copies here > at work ;-) > > --Tony > > Blaine Lang wrote: > > >Hi Tony, > > > >I too have never been overly impressed with the ActiveState IDE. I just > >found it too slow on my WinXP desktop and it's not a under-powered desktop. > >I also recently tried the ZendStudio and liked it but I keep coming back to > >my super fast editor that I love to use - EditPlus. I do like the > >integrated debugger but I also found it slow at times - no where as bad as > >Komodo. I just hate it when I'm typing and there is a delay. > > > >My trial expired before I had given it enough hour of testing. I know there > >are many benefits and it takes time to change your style and get used to a > >new devel environment. > > > >Blaine > > > >----- Original Message ----- > >From: "Tony Bibbs" > >To: > >Sent: Tuesday, August 17, 2004 11:00 AM > >Subject: [geeklog-devel] Zend Editor > > > > > >I've tried, in vain, to get free professional edition copies of Zend > >Studio. The best they could offer was the academic discount of 25% > >off. That takes the $250 price tag down to $187. For what it is > >worth, my full trial version expired today and a few features got > >disabled. To my amazement, however, the debugger still works which...by > >itself is worth gold. > > > >That being said, I'd really encourage those who haven't tried it to give > >it a try. I've dumped my ActiveState license for Zend and I would have > >done so even if my employer wasn't buying us some licenses. The > >features that I have noticed that have been disabled is CVS integration > >and the introspection stuff which is handy but not terribly useful, IMHO. > > > >Anyway, let me know if anybody wants the full blown version at that price. > > > >--Tony > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Wed Aug 18 11:22:04 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 18 Aug 2004 10:22:04 -0500 Subject: [geeklog-devel] Zend Editor In-Reply-To: References: <41221D81.8040505@tonybibbs.com> <067e01c484cb$2c0eee20$650a10ac@XPBL2> <41236ED6.7090806@tonybibbs.com> Message-ID: <4123741C.4000305@tonybibbs.com> Look, he speaks. --Tony Justin Carlson wrote: >Yes, it's the only way he can get me off of Vim >It's the first setup I've liked well enough to change my ways. > >- Justin > >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Wednesday, August 18, 2004 8:59 AM >Subject: Re: [geeklog-devel] Zend Editor > > > > >>Yeah, this does become a coke vs pepsi sort of argument but you should >>try the new version compatible with PHP5. Granted I have a pretty hefty >>laptop but everything is quite snappy. Right click menus, debugging, >>code analyzer, etc all work faster than I could tolerate (which is good). >> >>IMHO, the debugger alone with the standard watches, breakpoints, call >>stack, etc is worth it. >> >>For me it is also a no brainer, we are getting professional copies here >>at work ;-) >> >>--Tony >> >>Blaine Lang wrote: >> >> >> >>>Hi Tony, >>> >>>I too have never been overly impressed with the ActiveState IDE. I just >>>found it too slow on my WinXP desktop and it's not a under-powered >>> >>> >desktop. > > >>>I also recently tried the ZendStudio and liked it but I keep coming back >>> >>> >to > > >>>my super fast editor that I love to use - EditPlus. I do like the >>>integrated debugger but I also found it slow at times - no where as bad >>> >>> >as > > >>>Komodo. I just hate it when I'm typing and there is a delay. >>> >>>My trial expired before I had given it enough hour of testing. I know >>> >>> >there > > >>>are many benefits and it takes time to change your style and get used to >>> >>> >a > > >>>new devel environment. >>> >>>Blaine >>> >>>----- Original Message ----- >>>From: "Tony Bibbs" >>>To: >>>Sent: Tuesday, August 17, 2004 11:00 AM >>>Subject: [geeklog-devel] Zend Editor >>> >>> >>>I've tried, in vain, to get free professional edition copies of Zend >>>Studio. The best they could offer was the academic discount of 25% >>>off. That takes the $250 price tag down to $187. For what it is >>>worth, my full trial version expired today and a few features got >>>disabled. To my amazement, however, the debugger still works which...by >>>itself is worth gold. >>> >>>That being said, I'd really encourage those who haven't tried it to give >>>it a try. I've dumped my ActiveState license for Zend and I would have >>>done so even if my employer wasn't buying us some licenses. The >>>features that I have noticed that have been disabled is CVS integration >>>and the introspection stuff which is handy but not terribly useful, IMHO. >>> >>>Anyway, let me know if anybody wants the full blown version at that >>> >>> >price. > > >>>--Tony >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From justin at w3abode.com Wed Aug 18 11:45:08 2004 From: justin at w3abode.com (Justin Carlson) Date: Wed, 18 Aug 2004 09:45:08 -0600 Subject: [geeklog-devel] Javascript menu References: <4122C5A6.10303@trumbower.com> Message-ID: <001501c4853a$58a237c0$05030a0a@ITDJCARLSOdev> At least twice in the first few times viewing it in IE the entire list did not show up. The spacing is tight in Mozilla 1.7.2, the colors and graphics looked correct for me. - Justin ----- Original Message ----- From: "Dwight Trumbower" To: Sent: Tuesday, August 17, 2004 8:57 PM Subject: Re: [geeklog-devel] Javascript menu > Looks nice in IE, not so nice in Mozilla. > > Simon Lord wrote: > > > I was fortunate to come across the following script via a buddy. It has > > to be the smallest javascript code and css I've ever seen supporting a > > wickedly cool hierarchical menu system. > > > > I spent the day making new icons for it and totally rewriting the css so > > it looks better. If any genius here thinks they can tie it into the > > Topics block then please send me your hack. Ideally the topic name > > would be the main link with the story names being the items with the > > menu. I have a hardcoded version working here: > > > > http://www.karbonized.com/dmx/ > > > > Hopefully the file (9k) is attached below... > > > > > > > > > > Sincerely, > > Simon > > > > ------------------------------------------------------------------------ > > > > > > > > ------------------------------------------------------------------------ > > > > avast! Antivirus : Inbound message clean. > > > > > > ---------------------------------------------------------------------------- ---- From slord at marelina.com Wed Aug 18 12:40:52 2004 From: slord at marelina.com (Simon Lord) Date: Wed, 18 Aug 2004 12:40:52 -0400 Subject: [geeklog-devel] Javascript menu In-Reply-To: <001501c4853a$58a237c0$05030a0a@ITDJCARLSOdev> References: <4122C5A6.10303@trumbower.com> <001501c4853a$58a237c0$05030a0a@ITDJCARLSOdev> Message-ID: <5E625C72-F135-11D8-A35E-003065C030F2@marelina.com> > At least twice in the first few times viewing it in IE the entire list > did > not show up. Yeah, this is likely a coincidence of you viewing the page while I was debugging my css this morning. I have it at a setting I like right now and will leave it this was for a few days. > The spacing is tight in Mozilla 1.7.2, the colors and graphics looked > correct for me. > - Justin > > > ----- Original Message ----- > From: "Dwight Trumbower" > To: > Sent: Tuesday, August 17, 2004 8:57 PM > Subject: Re: [geeklog-devel] Javascript menu > > >> Looks nice in IE, not so nice in Mozilla. >> >> Simon Lord wrote: >> >>> I was fortunate to come across the following script via a buddy. It >>> has >>> to be the smallest javascript code and css I've ever seen supporting >>> a >>> wickedly cool hierarchical menu system. >>> >>> I spent the day making new icons for it and totally rewriting the >>> css so >>> it looks better. If any genius here thinks they can tie it into the >>> Topics block then please send me your hack. Ideally the topic name >>> would be the main link with the story names being the items with the >>> menu. I have a hardcoded version working here: >>> >>> http://www.karbonized.com/dmx/ >>> >>> Hopefully the file (9k) is attached below... >>> >>> >>> >>> >>> Sincerely, >>> Simon >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> avast! Antivirus : Inbound message clean. >>> >>> >> >> > > > ----------------------------------------------------------------------- > ----- > ---- > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > Sincerely, Simon From dirk at haun-online.de Fri Aug 20 06:02:16 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 20 Aug 2004 12:02:16 +0200 Subject: [geeklog-devel] FYI: md5 weakness found Message-ID: <20040820110216.22841@smtp.haun-online.de> For those who didn't see it: Apparently, md5 is a lot less secure than it seemed. After some initial confusion, it has now been confirmed that a way has been found to produce collisions in md5 much more efficiently than before. In other words, given enough time and the proper access, there is now a more efficient way to come up with a pass phrase that has the same md5 checksum as the original password - without having to know that original password. There's no need to panic, though, as even the new way still requires a lot of computing power and retries which would be detected under normal circumstances. We should, however, keep in mind not to use md5 in the future and switch over to something else - as soon as the experts have come up with a viable alternative. A short summary is here: To quote: "Where does this leave us? MD5 is fatally wounded; its use will be phased out. SHA-1 is still alive but the vultures are circling. A gradual transition away from SHA-1 will now start. The first stage will be a debate about alternatives, leading (I hope) to a consensus among practicing cryptographers about what the substitute will be." Slashdot also carries the story: bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From slord at marelina.com Fri Aug 20 10:45:25 2004 From: slord at marelina.com (Simon Lord) Date: Fri, 20 Aug 2004 10:45:25 -0400 Subject: [geeklog-devel] Deleting topics Message-ID: <92201F1D-F2B7-11D8-A35E-003065C030F2@marelina.com> I *really* don't like it that GL deletes my stories and blocks associated with my topics. Sigh. Sincerely, Simon From tony at tonybibbs.com Fri Aug 20 10:53:34 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 20 Aug 2004 09:53:34 -0500 Subject: [geeklog-devel] Input From PJ of Groklaw Message-ID: <4126106E.9040505@tonybibbs.com> I recently was made aware of some issues Groklaw was having. Seems as though Stories and commennts come up missing sporadically. I contacted PJ and she says she's been working with Rakaz (she calls him MathFox). on the issues. If anybody sees Rakaz in IRC they should bring this up and see how we might help. Also, any changes related to performance that we have made we should share with Groklaw immediate so they might modify their existing code (vinny I think I saw CVS commits from you in particular related to performance and comments). Aside from that PJ had a number of feature requests so I'm putting them here so that they will be considered in either of the branches: 1) PJ likes to have a couple versions of the same page loaded. In one she uses to view the article, in the othe she edits it. She'd like away to do this in one page. 2) Comment moderation has been mentioned numerous times. However, her request is that admins would be able to moderate the comments. I think that is a bit more realistic (and useful). 3) She would like to mark bad comments as hidden (basic trolling). Naturally they would show up for the admin but not the regular users. 4) She would like quotations, blocks of text in an article, to optionally have a slightly darker shading than the rest of the page, so it would be clearly a quotation, without having to use quotation marks. Blaine can we borrow the forum code for this? 5) She'd like pagination of commments. This is a good idea as it would help performance. 6) She'd like users to edit their own comments and even delete them if no one has responded to it yet. 7) Similar to #1 she wants to be able to edit and review a static page in one sweep. 8) Add the ability to convert a PDF to plain text (great idea to compliment our new PDF generation) 9) This one is hard to rearticulate so I'm quoting her exactly: "It would be nice if there could be a work area, where everyone could work on a document together, which I could let certain groups have access to. It's the single hardest part of Groklaw, the difficulty of working together fast when we're all over the world. I know I could do it now if I give everyone the power, but for security reasons, it has to be a walled off area, so they can't wander about. My readers know how to do everything, and sometimes we get volunteers with an agenda, so I need to be careful. When we do audio transcripts, for example, we typically break it up into mp3s and then everyone gets sent one. It would be pleasant to be able to have folks just come and grab what they want and have a place to input the result on Groklaw, instead of it all being funneled through me." Obviously some of these we've seen before. Some we haven't. I think quite a few are low hanging fruit and others would take quite a bit of work. Nonetheless, I think we should consider these. I know in a truly democratic system (which this isn't necessarily) we give all users the same say but I think we would be wise to at least address a few of these ideas as I'd hate to see Groklaw change platforms. To be clear, changing platforms wasn't mentioned in the message she sent me but I can't imagine it wasn't thought off considering they have content disappearing. Also, this may be a good time to try recruiting more help off of geeklog.net. I was surprised at the help I got for Auth_Enterprise by nagging people there. I think if we create a request for help and list some of these request (along with any prexisting issues on the project site) and drop Groklaw's name we might get more help because....well, nobody really wants to see SCO win this thing and helping, even if in this indirect way, would probably motivate people. Thoughts, questions or concerns? --Tony From vfuria at gmail.com Fri Aug 20 11:30:42 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 20 Aug 2004 11:30:42 -0400 Subject: [geeklog-devel] Input From PJ of Groklaw In-Reply-To: <4126106E.9040505@tonybibbs.com> References: <4126106E.9040505@tonybibbs.com> Message-ID: <8319e2d604082008307b8a49bd@mail.gmail.com> 5) Comment Pagination: Already checked into CVS. And yes, big performance improvement on stories with LOTS of comments. I haven't seen Rakaz around in a while, but next time I see him I'll let him know the details of all the performance improvements I've added. I can't imagine what would cause stories and comments to diappear. There a couple places where, using my imagination, I could see multiple Admins editing or adding an item at the same time could cause problems, but that is more likely just some corruption rather than "disappearance". -Vinny On Fri, 20 Aug 2004 09:53:34 -0500, Tony Bibbs wrote: > I recently was made aware of some issues Groklaw was having. Seems as > though Stories and commennts come up missing sporadically. I contacted > PJ and she says she's been working with Rakaz (she calls him MathFox). > on the issues. If anybody sees Rakaz in IRC they should bring this up > and see how we might help. Also, any changes related to performance > that we have made we should share with Groklaw immediate so they might > modify their existing code (vinny I think I saw CVS commits from you in > particular related to performance and comments). > > Aside from that PJ had a number of feature requests so I'm putting them > here so that they will be considered in either of the branches: > > 1) PJ likes to have a couple versions of the same page loaded. In one > she uses to view the article, in the othe she edits it. She'd like away > to do this in one page. > 2) Comment moderation has been mentioned numerous times. However, her > request is that admins would be able to moderate the comments. I think > that is a bit more realistic (and useful). > 3) She would like to mark bad comments as hidden (basic trolling). > Naturally they would show up for the admin but not the regular users. > 4) She would like quotations, blocks of text in an article, to > optionally have a slightly darker shading than the rest of the page, so > it would be clearly a quotation, without having to use quotation marks. > Blaine can we borrow the forum code for this? > 5) She'd like pagination of commments. This is a good idea as it would > help performance. > 6) She'd like users to edit their own comments and even delete them if > no one has responded to it yet. > 7) Similar to #1 she wants to be able to edit and review a static page > in one sweep. > 8) Add the ability to convert a PDF to plain text (great idea to > compliment our new PDF generation) > 9) This one is hard to rearticulate so I'm quoting her exactly: "It > would be nice if there could be a work area, where everyone could work > on a document together, which I could let certain groups have access > to. It's the single hardest part of Groklaw, the difficulty of working > together fast when we're all over the world. I know I could do it now > if I give everyone the power, but for security reasons, it has to be a > walled off area, so they can't wander about. My readers know how to do > everything, and sometimes we get volunteers with an agenda, so I need to > be careful. When we do audio transcripts, for example, we typically > break it up into mp3s and then everyone gets sent one. It would be > pleasant to be able to have folks just come and grab what they want and > have a place to input the result on Groklaw, instead of it all being > funneled through me." > > Obviously some of these we've seen before. Some we haven't. I think > quite a few are low hanging fruit and others would take quite a bit of > work. Nonetheless, I think we should consider these. I know in a truly > democratic system (which this isn't necessarily) we give all users the > same say but I think we would be wise to at least address a few of these > ideas as I'd hate to see Groklaw change platforms. To be clear, > changing platforms wasn't mentioned in the message she sent me but I > can't imagine it wasn't thought off considering they have content > disappearing. > > Also, this may be a good time to try recruiting more help off of > geeklog.net. I was surprised at the help I got for Auth_Enterprise by > nagging people there. I think if we create a request for help and list > some of these request (along with any prexisting issues on the project > site) and drop Groklaw's name we might get more help because....well, > nobody really wants to see SCO win this thing and helping, even if in > this indirect way, would probably motivate people. > > Thoughts, questions or concerns? > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Fri Aug 20 11:35:33 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 20 Aug 2004 11:35:33 -0400 Subject: [geeklog-devel] Slow Vinny Message-ID: <8319e2d604082008352a066008@mail.gmail.com> So you probably noticed I haven't been around much in the past several days, and that I haven't been doing much work in CVS. That is because I'm in the middle of a move. I expected to have a bit of down time to work on Geeklog stuff, but it hasn't materialized yet. I should be back to my normal productive self in another week or so. I have two items left for 1.3.10 that I want to work on, but obviously I won't be able to for about a week. These are: 1. Fix comment formatting under IE in certain situations 2. Add Admin options to comments when in the view and display modes So please be patient. If someone is impatient they are more than welcome to look into these problems themselves, I certainly would not mind. Also, if there are any Geeks in the Washington, DC area who are interested in helping unload a moving van tomorrow (Saturday, 8/21) afternoon please drop me an email. :) Thanks, see everyone in a week. -Vinny From tony at tonybibbs.com Fri Aug 20 11:36:46 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 20 Aug 2004 10:36:46 -0500 Subject: [geeklog-devel] [Fwd: Re: Geeklog and Groklaw] Message-ID: <41261A8E.4030906@tonybibbs.com> Some clarification to the list I sent. --Tony -------- Original Message -------- Subject: Re: Geeklog and Groklaw Date: Fri, 20 Aug 2004 15:21:50 +0000 From: Pamela Jones To: Tony Bibbs References: <200408182042.i7IKgpu32509 at statler.metalab.unc.edu> <69B65C55-F17F-11D8-9895-000D93C0C6E2 at groklaw.com> <412610B2.1000109 at tonybibbs.com> Hi Tony, Couple of things: rakaz and mathfox are two different people, but both work on Groklaw. But mathfox is the webmaster. Second, on the request you list as number one: I need to explain better. What mathfox has said is that if I simultaneously open up two copies of the same page of Groklaw, it can cause problems. I would like to be able to do that, because of the reasons I mentioned. But on that request (as distinct from my request re static pages), I am not asking that it be viewable on the same page. Two open at the same time without crashing. Also, on public requests for help. Please remove the moderator request regarding hiding. I have enough diligent Utah people attacking me for moderating as it is. I'd appreciate keeping that part more private. Thanks, PJ On Fri, 2004-08-20 at 14:54, Tony Bibbs wrote: > I've forwarded your input on to our developers and cc'd you both in. > PJ, as you think of more things feel free to send them to me. > > Thanks, > > --Tony > > Pamela Jones wrote: > > > Hi Tony, > > > > Thank you for Geeklog. I've enjoyed it a lot. I'm thrilled to hear you > > are working on making it scale, and just in time! I think there are > > some issues having to do with scale that we are starting to run into. > > MathFox has done some personalizing, as you probably know. But with > > a thousand comments on a story yesterday, well...it's a lot. > > > > He thinks maybe I caused the problem with the disappearing stories, by > > having three different pages of Groklaw open at the same time. I don't > > think that is it, though, because I wasn't working on Groklaw at the > > time, and was doing email instead when it happened. On the other hand, > > he's usually right. It might be a good idea if you contact him and you > > two can talk with more specifics. I'm cc'ing him with this. > > > > Also, comments are starting to disappear sometimes. I don't know > > why. We are analyzing the logs now, so I can't really answer your > > question as to why yet. We have issues with bandwidth because ibiblio > > rations us, and sometimes it's hard to know what is a real problem and > > what is just an ibiblio issue. But when the disappearing stories went > > poof, all three turned up as drafts, but early versions, missing huge > > chunks, and with comments attached, but not necessarily attached to > > the right story. When I looked at the stats, it would say 6 hits, 27 > > comments, which is impossible, obviously, or at least inconceivable, > > and there wouldn't be 27 comments in any case, so while some data was > > saved, it was garbled. > > > > I'm generally a problem. I do like to open several pages at once and > > work that way, and MathFox scolds me about that. If you could make it > > so I could do that, I'd be thrilled. For example, I like to open an > > article and go down the comments and have a second window open with > > the page where I can edit any mistakes I've made and readers catch. > > > > Also, in a perfect world, I'd be able to go through comments, flag the > > really good ones and they'd show up in a special place at the top of > > the list, a kind of Best of the Comments on this Article, so really > > busy folks could just read those. I'd like it so I could "anoint" a > > crew to handle that choosing. With me being able to overrule them. > > > > I'd also love it if I could hide comments and have them show up > > nowhere unless I made them visible again. The troll dance. That way > > moderators could hide a comment, and I could later go through and > > either confirm by deleting or restore, if they go too far. But they'd > > have to disappear from search and every form of view. > > > > Another thing I'd love would be if we could have it so quotations, > > blocks of text in an article, could optionally have a slightly darker > > shading than the rest of the page, so it would be clearly a quotation, > > without having to use quotation marks. > > > > It would be nice if there could be a work area, where everyone could > > work on a document together, which I could let certain groups have > > access to. It's the single hardest part of Groklaw, the difficulty of > > working together fast when we're all over the world. I know I could > > do it now if I give everyone the power, but for security reasons, it > > has to be a walled off area, so they can't wander about. My readers > > know how to do everything, and sometimes we get volunteers with an > > agenda, so I need to be careful. When we do audio transcripts, for > > example, we typically break it up into mp3s and then everyone gets > > sent one. It would be pleasant to be able to have folks just come and > > grab what they want and have a place to input the result on Groklaw, > > instead of it all being funneled through me. > > > > I'd love it if there was a way to have comments up to a certain number > > and then they'd click to read the rest. When we get 400 plus per > > story, and sometimes more than twice that, it slows things down quite > > a lot. If the only way to do it is a la Slashdot, though, I'd rather > > stick to what we have already. I hate the Slashdot method, because it > > repeats way too many comments on the next page. > > > > Sometimes readers ask for the ability to edit their own comments or > > even delete them. > > > > It would be very nice if the static pages could be viewed in edit. For > > example, if I want to edit the IBM timeline page, I have to open two > > windows to be able to see what I'm doing, because in edit, you see > > only the html, not the finished look, and you really want both. > > > > Someone is trying to work out a way to write a script to quickly > > change a pdf to plain text. If it were built in, my whole life would > > get better. > > > > Sorry you asked yet? > > > > : ) > > > > When we figure out what happened with the disappearing story, I'll > > write to you again and let you know. > > > > I love the idea of working together, because there will surely be more > > Groklaws in the future. Mathfox has, I believe, donated some stuff > > back. But some things we kind of keep under wraps for the moment, > > mainly because I'd rather the astroturfers not know all our tricks. > > > > PJ > > > > > > > > > > > > > > > > > > > > > > On Aug 18, 2004, at 4:42 PM, tony_bibbs wrote: > > > >> PJ, > >> > >> I'm Tony Bibbs, one of the maintainers for Geeklog. We have watched > >> Groklaw grow and have been excited to see it has, for the most part, > >> grown with the site. I noticed you have run into a problem with lost > >> stories and I'd like to get some insight into the cause so we might > >> address this should it prove to be an issue with the Geeklog code or > >> the Geeklog database. > >> > >> I've read many of the posts related to this and everybody seemed to > >> have an opinion on how to improve things. Mine is quite simply, let > >> us work with you to address any issues you might have...it only helps > >> us make Geeklog better and you get, I hope, the reassurance we value > >> you and your site. > >> > >> So that you know, I'm responsible for the next version of Geeklog > >> (version 2) and it is going to be built with large scale deployments > >> in mind and will include an upgrade path from 1.3.x. To that end if > >> you have any suggestions on how we might improve Geeklog we would > >> love any feedback you might have. > >> > >> Thanks, > >> > >> --Tony > >> > > From mathfox at xs4all.nl Fri Aug 20 11:46:41 2004 From: mathfox at xs4all.nl (Peter Roozemaal) Date: Fri, 20 Aug 2004 17:46:41 +0200 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <4126106E.9040505@tonybibbs.com> References: <4126106E.9040505@tonybibbs.com> Message-ID: <41261CE1.7060806@xs4all.nl> Hello all, Tony Bibbs wrote: > I recently was made aware of some issues Groklaw was having. Seems as > though Stories and commennts come up missing sporadically. I contacted > PJ and she says she's been working with Rakaz (she calls him MathFox). Rakaz (Niels) is another person than me. > on the issues. If anybody sees Rakaz in IRC they should bring this up > and see how we might help. Also, any changes related to performance > that we have made we should share with Groklaw immediate so they might > modify their existing code (vinny I think I saw CVS commits from you in > particular related to performance and comments). The database is the most serious performance bottleneck. We have 7? webservers talking to a single database and Geeklog does a lot of queries per page. We have a few stories with over 1000 comments! Another issue is that regular expressions can take huge amounts of CPU time when stories go large. PJ writes stories that don't allways fit in 64k, so I enlarged the bodytext field to mediumtext (16M). The regular expression match in COM_extractLinks caused a time-out in stories that had more that 50 links. (footnotes and back). BTW, we dropped the "what's related" box. > Aside from that PJ had a number of feature requests so I'm putting them > here so that they will be considered in either of the branches: > [...] > > Obviously some of these we've seen before. Some we haven't. I think > quite a few are low hanging fruit and others would take quite a bit of > work. Nonetheless, I think we should consider these. I know in a truly > democratic system (which this isn't necessarily) we give all users the > same say but I think we would be wise to at least address a few of these > ideas as I'd hate to see Groklaw change platforms. To be clear, > changing platforms wasn't mentioned in the message she sent me but I > can't imagine it wasn't thought off considering they have content > disappearing. I have been looking for a suitable platform, but couldn't find another one that 1. was open source 2. had a decent security record 3. could be installed easily 4. had a good management interface and I'ld hate to convert databases to a new environment. > Also, this may be a good time to try recruiting more help off of > geeklog.net. I was surprised at the help I got for Auth_Enterprise by > nagging people there. I think if we create a request for help and list > some of these request (along with any prexisting issues on the project > site) and drop Groklaw's name we might get more help because....well, > nobody really wants to see SCO win this thing and helping, even if in > this indirect way, would probably motivate people. Greetings, Peter. From dirk at haun-online.de Fri Aug 20 11:59:16 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 20 Aug 2004 17:59:16 +0200 Subject: [geeklog-devel] Input From PJ of Groklaw In-Reply-To: <4126106E.9040505@tonybibbs.com> References: <4126106E.9040505@tonybibbs.com> Message-ID: <20040820165916.21210@smtp.haun-online.de> >4) She would like quotations, blocks of text in an article, to >optionally have a slightly darker shading than the rest of the page, so >it would be clearly a quotation, without having to use quotation marks. Is this meant for articles only? Or also for comments? For articles posted by moderators, a workaround using and some CSS would do the trick. This is, of course, probably too complicated for the normal user. bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From tony at tonybibbs.com Fri Aug 20 11:58:37 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 20 Aug 2004 10:58:37 -0500 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <41261CE1.7060806@xs4all.nl> References: <4126106E.9040505@tonybibbs.com> <41261CE1.7060806@xs4all.nl> Message-ID: <41261FAD.7070400@tonybibbs.com> > Rakaz (Niels) is another person than me. Sorry about that. Us techies get caught up in IRC/system names instead of real names it's not hard to do. Apologies to you and Niels. > The database is the most serious performance bottleneck. We have 7? > webservers talking to a single database and Geeklog does a lot of > queries per page. We have a few stories with over 1000 comments! Yeah, this is clearly a problem. We have recently implemented use of PHP sessions. We didn't do much with it other than store important things like $_USER in it but now that we have that we need to investigate using the single query made to populate $_SESSION form the database in ways that will prevent the lots of little queries that have cluttered the code. Given that we need to start reviewing the code again. Also, have you considered adding another database server and load balancing them? I think MySQL's replication has reached a point were you could do this reliably. Obvious it makes things more complex from the administration side but it might be worth investigating. > > Another issue is that regular expressions can take huge amounts of CPU > time when stories go large. PJ writes stories that don't allways fit in > 64k, so I enlarged the bodytext field to mediumtext (16M). The regular > expression match in COM_extractLinks caused a time-out in stories that > had more that 50 links. (footnotes and back). BTW, we dropped the > "what's related" box. Hrm, good idea. Dirk, it might be worth upgrading that field. Yeah, the regex's would be a killer on larger stories. Thanks, we'll review it and see how we can fix this. > I have been looking for a suitable platform, but couldn't find another > one that > 1. was open source > 2. had a decent security record > 3. could be installed easily > 4. had a good management interface > and I'ld hate to convert databases to a new environment. Well, like I said, we want to be sure that Geeklog grows as the needs of the communities grow. Groklaw is an outlier in terms of size but our goal is to support sites that become this successful. I hope that by working together we can get to a point where Geeklog is sleeker, meaner and cleaner. All this reminds me of where Mozilla is with Thunderbird and Firefox. I think Geeklog is to a point where we need to bust out with code analyzing an realling streamlining things. Any chance we might be able to get a copy of the Groklaw DB? I know that is asking a lot but it would help us a lot. --Tony From geeklog at langfamily.ca Fri Aug 20 12:04:16 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Fri, 20 Aug 2004 12:04:16 -0400 Subject: [geeklog-devel] Input From PJ of Groklaw References: <4126106E.9040505@tonybibbs.com> <20040820165916.21210@smtp.haun-online.de> Message-ID: <005401c486cf$57c643a0$650a10ac@XPBL2> I wonder if we should consider implementing the PEAR Text_Wiki class http://pear.php.net/package/Text_Wiki/ More details found on this page: http://wiki.ciaweb.net/yawiki/index.php?area=Text_Wiki It is not a full wiki and only does the transformation to the target output. Blaine ----- Original Message ----- From: "Dirk Haun" To: Sent: Friday, August 20, 2004 11:59 AM Subject: Re: [geeklog-devel] Input From PJ of Groklaw >4) She would like quotations, blocks of text in an article, to >optionally have a slightly darker shading than the rest of the page, so >it would be clearly a quotation, without having to use quotation marks. Is this meant for articles only? Or also for comments? For articles posted by moderators, a workaround using and some CSS would do the trick. This is, of course, probably too complicated for the normal user. bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Fri Aug 20 12:08:16 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 20 Aug 2004 11:08:16 -0500 Subject: [geeklog-devel] Input From PJ of Groklaw In-Reply-To: <005401c486cf$57c643a0$650a10ac@XPBL2> References: <4126106E.9040505@tonybibbs.com> <20040820165916.21210@smtp.haun-online.de> <005401c486cf$57c643a0$650a10ac@XPBL2> Message-ID: <412621F0.9000803@tonybibbs.com> Would this be worth while? http://pear.php.net/package/HTML_BBCodeParser It might be a suitable way for hacking around the crap I use for images in articles. --Tony Blaine Lang wrote: >I wonder if we should consider implementing the PEAR Text_Wiki class >http://pear.php.net/package/Text_Wiki/ > >More details found on this page: >http://wiki.ciaweb.net/yawiki/index.php?area=Text_Wiki > >It is not a full wiki and only does the transformation to the target output. > >Blaine > >----- Original Message ----- >From: "Dirk Haun" >To: >Sent: Friday, August 20, 2004 11:59 AM >Subject: Re: [geeklog-devel] Input From PJ of Groklaw > > > > >>4) She would like quotations, blocks of text in an article, to >>optionally have a slightly darker shading than the rest of the page, so >>it would be clearly a quotation, without having to use quotation marks. >> >> > >Is this meant for articles only? Or also for comments? For articles >posted by moderators, a workaround using and some >CSS would do the trick. This is, of course, probably too complicated for >the normal user. > >bye, Dirk > > > > From vfuria at gmail.com Fri Aug 20 12:22:40 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 20 Aug 2004 12:22:40 -0400 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <41261CE1.7060806@xs4all.nl> References: <4126106E.9040505@tonybibbs.com> <41261CE1.7060806@xs4all.nl> Message-ID: <8319e2d6040820092278b90fbd@mail.gmail.com> On Fri, 20 Aug 2004 17:46:41 +0200, Peter Roozemaal wrote: > The database is the most serious performance bottleneck. We have 7? > webservers talking to a single database and Geeklog does a lot of > queries per page. We have a few stories with over 1000 comments! > I implemented tons of changes in current CVS (1.3.10) that will reduce the number of DB queries by a LOT. Many (but by no means all) of these changes were to comments and articles which reduces query time by an order of magnitude for stories with lots of comments. Now one query will fetch all the comments and a typical article page load has fewer than 50 queries (as opposed to about 150 (+ 1 per comment) in 1.3.9). Of course more testing will be required before I'd recommend throwing these on a production system (especially Groklaw). -Vinny From geeklog at langfamily.ca Fri Aug 20 12:33:18 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Fri, 20 Aug 2004 12:33:18 -0400 Subject: [geeklog-devel] Input From PJ of Groklaw References: <4126106E.9040505@tonybibbs.com> <20040820165916.21210@smtp.haun-online.de> <005401c486cf$57c643a0$650a10ac@XPBL2> <412621F0.9000803@tonybibbs.com> Message-ID: <006201c486d3$6643b030$650a10ac@XPBL2> I think I looked at this some months ago ... it does not include the formatting for quotes other then the " type Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Friday, August 20, 2004 12:08 PM Subject: Re: [geeklog-devel] Input From PJ of Groklaw Would this be worth while? http://pear.php.net/package/HTML_BBCodeParser It might be a suitable way for hacking around the crap I use for images in articles. --Tony Blaine Lang wrote: >I wonder if we should consider implementing the PEAR Text_Wiki class >http://pear.php.net/package/Text_Wiki/ > >More details found on this page: >http://wiki.ciaweb.net/yawiki/index.php?area=Text_Wiki > >It is not a full wiki and only does the transformation to the target output. > >Blaine > >----- Original Message ----- >From: "Dirk Haun" >To: >Sent: Friday, August 20, 2004 11:59 AM >Subject: Re: [geeklog-devel] Input From PJ of Groklaw > > > > >>4) She would like quotations, blocks of text in an article, to >>optionally have a slightly darker shading than the rest of the page, so >>it would be clearly a quotation, without having to use quotation marks. >> >> > >Is this meant for articles only? Or also for comments? For articles >posted by moderators, a workaround using and some >CSS would do the trick. This is, of course, probably too complicated for >the normal user. > >bye, Dirk > > > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From mathfox at xs4all.nl Fri Aug 20 12:29:36 2004 From: mathfox at xs4all.nl (Peter Roozemaal) Date: Fri, 20 Aug 2004 18:29:36 +0200 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <41261FAD.7070400@tonybibbs.com> References: <4126106E.9040505@tonybibbs.com> <41261CE1.7060806@xs4all.nl> <41261FAD.7070400@tonybibbs.com> Message-ID: <412626F0.6020304@xs4all.nl> Tony Bibbs wrote: >> The database is the most serious performance bottleneck. We have 7? >> webservers talking to a single database and Geeklog does a lot of >> queries per page. We have a few stories with over 1000 comments! > > Yeah, this is clearly a problem. We have recently implemented use of > PHP sessions. We didn't do much with it other than store important > things like $_USER in it but now that we have that we need to > investigate using the single query made to populate $_SESSION form the > database in ways that will prevent the lots of little queries that have > cluttered the code. Given that we need to start reviewing the code again. PHP session variables create a load on the central file server. We can not store them locally on the webserver as the loadbalancer will move sessions from machine to machine. (rethinks) It might be possible if the session variable only serves as cache for database data. > Also, have you considered adding another database server and load > balancing them? I think MySQL's replication has reached a point were > you could do this reliably. Obvious it makes things more complex from > the administration side but it might be worth investigating. We need a bit of help from your side in separating read-only database operations from operations that modify the database. The config files would need two database names, etc. >> Another issue is that regular expressions can take huge amounts of CPU >> time when stories go large. PJ writes stories that don't allways fit in >> 64k, so I enlarged the bodytext field to mediumtext (16M). The regular >> expression match in COM_extractLinks caused a time-out in stories that >> had more that 50 links. (footnotes and back). BTW, we dropped the >> "what's related" box. > > Hrm, good idea. Dirk, it might be worth upgrading that field. Yeah, the > regex's would be a killer on larger stories. Thanks, we'll review it > and see how we can fix this. > >> I have been looking for a suitable platform, but couldn't find another >> one that >> 1. was open source >> 2. had a decent security record >> 3. could be installed easily >> 4. had a good management interface >> and I'ld hate to convert databases to a new environment. > > Well, like I said, we want to be sure that Geeklog grows as the needs of > the communities grow. Groklaw is an outlier in terms of size but our > goal is to support sites that become this successful. I hope that by > working together we can get to a point where Geeklog is sleeker, meaner > and cleaner. All this reminds me of where Mozilla is with Thunderbird > and Firefox. I think Geeklog is to a point where we need to bust out > with code analyzing an realling streamlining things. Any chance we > might be able to get a copy of the Groklaw DB? I know that is asking a > lot but it would help us a lot. I can give you a sanitized version of the database if there is a place where I can upload a 45 Mbyte of compressed data. I need a few hours to clean it from personal data. Greetings, Peter. From tony at tonybibbs.com Fri Aug 20 13:50:44 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 20 Aug 2004 12:50:44 -0500 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <412626F0.6020304@xs4all.nl> References: <4126106E.9040505@tonybibbs.com> <41261CE1.7060806@xs4all.nl> <41261FAD.7070400@tonybibbs.com> <412626F0.6020304@xs4all.nl> Message-ID: <412639F4.80809@tonybibbs.com> Peter Roozemaal wrote: > PHP session variables create a load on the central file server. We can > not store them locally on the webserver as the loadbalancer will move > sessions from machine to machine. (rethinks) It might be possible if the > session variable only serves as cache for database data. Using files versus a DB is the admin's decision. In your case you'd clearly need the DB. > We need a bit of help from your side in separating read-only database > operations from operations that modify the database. The config files > would need two database names, etc. Hrm, haven't thought about this much. Deserves some more thought from all of us. Also, have you turned on query caching in MySQL. I'm guessing you have but that would help a lot. > I can give you a sanitized version of the database if there is a place > where I can upload a 45 Mbyte of compressed data. I need a few hours to > clean it from personal data. k, Let me know when you get it ready and I'll let you SCP it to one of our servers. --Tony From dirk at haun-online.de Fri Aug 20 14:49:29 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 20 Aug 2004 20:49:29 +0200 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <41261FAD.7070400@tonybibbs.com> References: <41261FAD.7070400@tonybibbs.com> Message-ID: <20040820194929.22305@smtp.haun-online.de> Tony Bibbs wrote: >> The regular >> expression match in COM_extractLinks caused a time-out in stories that >> had more that 50 links. (footnotes and back). >Hrm, good idea. Dirk, it might be worth upgrading that field. Yeah, the >regex's would be a killer on larger stories. Thanks, we'll review it >and see how we can fix this. There was a reason why I switched to have What's Related created dynamically - but I can't remember it :-/ bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From dirk at haun-online.de Fri Aug 20 14:46:38 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 20 Aug 2004 20:46:38 +0200 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <412626F0.6020304@xs4all.nl> References: <412626F0.6020304@xs4all.nl> Message-ID: <20040820194638.6425@smtp.haun-online.de> Peter Roozemaal wrote: >We need a bit of help from your side in separating read-only database >operations from operations that modify the database. Btw, have you tried switching to InnoDB tables (instead of MyISAM)? This seemed to help the guys over at macfixit.com 1.3.10 will use InnoDB tables on a fresh install (if the MySQL version used does support them). A script to convert existing DBs is included. bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From dirk at haun-online.de Sat Aug 21 07:27:59 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 21 Aug 2004 13:27:59 +0200 Subject: [geeklog-devel] Re: Input From PJ of Groklaw In-Reply-To: <20040820194929.22305@smtp.haun-online.de> References: <20040820194929.22305@smtp.haun-online.de> Message-ID: <20040821122759.20308@smtp.haun-online.de> I wrote: >There was a reason why I switched to have What's Related created >dynamically - but I can't remember it :-/ I remember now: The reason was that the 'related' field held not only the actual links but also the HTML for them, i.e. the entire content of the What's Related block. But of course that block could use different HTML for different themes. So the obvious solution would be to go back and use this field, but this time only store the actual links in there. This would still require some processing power when rendering the article, but it should be a lot less than the regular expressions would need. I'll look into it ... bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From tomw at pigstye.net Wed Aug 25 09:43:23 2004 From: tomw at pigstye.net (Tom Willett) Date: Wed, 25 Aug 2004 13:43:23 +0000 Subject: [geeklog-devel] Found a spam comment hole. In-Reply-To: <20040825011809.66131.qmail@web60407.mail.yahoo.com> References: <20040825011809.66131.qmail@web60407.mail.yahoo.com> Message-ID: <20040825133843.M40955@pigstye.net> Kyle noticed something we can change to cut down on the number of spam comments in geeklog.? He noticed in his logs the following google search after people tried to post spam comments. "post a comment" anonymous "Allowed HTML tags"? If you search for this you will find a series of links mostly to geeklog sites that point to the post a comment page all loaded and ready. Simply changing the 'Post a comment' link on stories to a form button would eliminate this problem. ---------- Forwarded Message ----------- From: Phandom/Keystone? To: Tom Willett Sent: Tue, 24 Aug 2004 18:18:09 -0700 (PDT) Subject: Thought you might find this interesting Hi Tom, ? ? I thought you might find this Google search interesting. I have found it in my webstats several times now after SpamX has blocked the spam comments from being posted on my sites. ? ?? "post a comment" anonymous "Allowed HTML tags"? ? ?? Kyle Supporting those on the front line of freedom! http://www.keystonesoldiers.com http://www.keystonemarines.com http://www.keystonesailors.com ------- End of Forwarded Message ------- -- Tom Willett From tony at tonybibbs.com Wed Aug 25 14:12:44 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 25 Aug 2004 13:12:44 -0500 Subject: [geeklog-devel] Update on Zend Licenses... Message-ID: <412CD69C.1050905@tonybibbs.com> In working with the Zend sales guy, he'd be willing to sell copies of Zend Studio for $125. I personally think we could get him down to $100. Anybody willing to pay that much for licenses? --Tony From dirk at haun-online.de Wed Aug 25 16:04:46 2004 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 25 Aug 2004 22:04:46 +0200 Subject: [geeklog-devel] Found a spam comment hole. In-Reply-To: <20040825133843.M40955@pigstye.net> References: <20040825133843.M40955@pigstye.net> Message-ID: <20040825210446.29200@smtp.haun-online.de> Tom, >If you search for this you will find a series of links mostly to geeklog >sites that point to the post a comment page all loaded and ready. Simply >changing the 'Post a comment' link on stories to a form button would >eliminate this problem. I would imagine that a button wouldn't look too good on most themes, though. We could list that in a "how to prevent comment spam" FAQ entry, though, together with the idea posted by Matthew Cox over on geeklog-devtalk, which is to add an entry for comment.php to your robots.txt We could also try some tricks with the referer, i.e. if referer does not contain $_CONF['site_url'] then don't display comment.php (but redirect to somewhere else). The problem with the latter approach is that the referer is somewhat unreliable (thus probably blocking a few legit users) and not too hard to fake. bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From mathfox at xs4all.nl Wed Aug 25 16:28:31 2004 From: mathfox at xs4all.nl (Peter Roozemaal) Date: Wed, 25 Aug 2004 22:28:31 +0200 Subject: [geeklog-devel] Found a spam comment hole. In-Reply-To: <20040825210446.29200@smtp.haun-online.de> References: <20040825133843.M40955@pigstye.net> <20040825210446.29200@smtp.haun-online.de> Message-ID: <412CF66F.5030208@xs4all.nl> Dirk Haun wrote: >>If you search for this you will find a series of links mostly to geeklog >>sites that point to the post a comment page all loaded and ready. Simply >>changing the 'Post a comment' link on stories to a form button would >>eliminate this problem. > > I would imagine that a button wouldn't look too good on most themes, though. > > We could list that in a "how to prevent comment spam" FAQ entry, though, > together with the idea posted by Matthew Cox over on geeklog-devtalk, > which is to add an entry for comment.php to your robots.txt > > We could also try some tricks with the referer, i.e. if referer does not > contain $_CONF['site_url'] then don't display comment.php (but redirect > to somewhere else). > > The problem with the latter approach is that the referer is somewhat > unreliable (thus probably blocking a few legit users) and not too hard to > fake. Groklaw has a link (from an external site) to a comment entry form. An automatic redirect on both the comment entry and comment submit would be very helpfull against stupid linking. Greetings, Peter. From geeklog at langfamily.ca Wed Aug 25 17:25:05 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 25 Aug 2004 17:25:05 -0400 Subject: [geeklog-devel] Update on Zend Licenses... References: <412CD69C.1050905@tonybibbs.com> Message-ID: <007b01c48ae9$fd152150$650a10ac@XPBL2> I think that I'd be interested in the Zend IDE at that price? Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Wednesday, August 25, 2004 2:12 PM Subject: [geeklog-devel] Update on Zend Licenses... In working with the Zend sales guy, he'd be willing to sell copies of Zend Studio for $125. I personally think we could get him down to $100. Anybody willing to pay that much for licenses? --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Wed Aug 25 17:35:18 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 25 Aug 2004 16:35:18 -0500 Subject: [geeklog-devel] Update on Zend Licenses... In-Reply-To: <007b01c48ae9$fd152150$650a10ac@XPBL2> References: <412CD69C.1050905@tonybibbs.com> <007b01c48ae9$fd152150$650a10ac@XPBL2> Message-ID: <412D0616.3050908@tonybibbs.com> I'll give the guy a call tomorrow and see if I can talk him down to $100. --Tony Blaine Lang wrote: >I think that I'd be interested in the Zend IDE at that price? > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Wednesday, August 25, 2004 2:12 PM >Subject: [geeklog-devel] Update on Zend Licenses... > > >In working with the Zend sales guy, he'd be willing to sell copies of >Zend Studio for $125. I personally think we could get him down to >$100. Anybody willing to pay that much for licenses? > >--Tony >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Thu Aug 26 09:42:37 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 26 Aug 2004 08:42:37 -0500 Subject: [geeklog-devel] gl-bot? Message-ID: <412DE8CD.5030301@tonybibbs.com> Where art thou? From vfuria at gmail.com Thu Aug 26 12:18:53 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 26 Aug 2004 12:18:53 -0400 Subject: [geeklog-devel] gl-bot? In-Reply-To: <412DE8CD.5030301@tonybibbs.com> References: <412DE8CD.5030301@tonybibbs.com> Message-ID: <8319e2d6040826091835a96d30@mail.gmail.com> gl-bot will be back. I need to get settled down into my new place first. You'll probably see him again this weekend with any luck. -Vinny On Thu, 26 Aug 2004 08:42:37 -0500, Tony Bibbs wrote: > Where art thou? > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Thu Aug 26 12:26:52 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 26 Aug 2004 12:26:52 -0400 Subject: [geeklog-devel] Update on Zend Licenses... In-Reply-To: <412D0616.3050908@tonybibbs.com> References: <412CD69C.1050905@tonybibbs.com> <007b01c48ae9$fd152150$650a10ac@XPBL2> <412D0616.3050908@tonybibbs.com> Message-ID: <8319e2d604082609265437a503@mail.gmail.com> I might be interested as well, I want to play around with the free version a bit more first though. -Vinny On Wed, 25 Aug 2004 16:35:18 -0500, Tony Bibbs wrote: > I'll give the guy a call tomorrow and see if I can talk him down to $100. > > --Tony > > > > Blaine Lang wrote: > > >I think that I'd be interested in the Zend IDE at that price? > > > >Blaine > >----- Original Message ----- > >From: "Tony Bibbs" > >To: > >Sent: Wednesday, August 25, 2004 2:12 PM > >Subject: [geeklog-devel] Update on Zend Licenses... > > > > > >In working with the Zend sales guy, he'd be willing to sell copies of > >Zend Studio for $125. I personally think we could get him down to > >$100. Anybody willing to pay that much for licenses? > > > >--Tony > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Thu Aug 26 16:08:14 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 26 Aug 2004 15:08:14 -0500 Subject: [geeklog-devel] Update on Zend Licenses... In-Reply-To: <8319e2d604082609265437a503@mail.gmail.com> References: <412CD69C.1050905@tonybibbs.com> <007b01c48ae9$fd152150$650a10ac@XPBL2> <412D0616.3050908@tonybibbs.com> <8319e2d604082609265437a503@mail.gmail.com> Message-ID: <412E432E.20206@tonybibbs.com> Ok, I've confirmed that I can get the license for $100. I need confirmation from anybody interested in buying a license. In the meantime I'll check with the sales guy to see how we can handle payment (i.e. all at once vs. individually) and how I can ensure your names get put on your individual license. --Tony Vincent Furia wrote: >I might be interested as well, I want to play around with the free >version a bit more first though. > >-Vinny > >On Wed, 25 Aug 2004 16:35:18 -0500, Tony Bibbs wrote: > > >>I'll give the guy a call tomorrow and see if I can talk him down to $100. >> >>--Tony >> >> >> >>Blaine Lang wrote: >> >> >> >>>I think that I'd be interested in the Zend IDE at that price? >>> >>>Blaine >>>----- Original Message ----- >>>From: "Tony Bibbs" >>>To: >>>Sent: Wednesday, August 25, 2004 2:12 PM >>>Subject: [geeklog-devel] Update on Zend Licenses... >>> >>> >>>In working with the Zend sales guy, he'd be willing to sell copies of >>>Zend Studio for $125. I personally think we could get him down to >>>$100. Anybody willing to pay that much for licenses? >>> >>>--Tony >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From geeklog at langfamily.ca Thu Aug 26 17:01:15 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 26 Aug 2004 17:01:15 -0400 Subject: [geeklog-devel] Update on Zend Licenses... References: <412CD69C.1050905@tonybibbs.com> <007b01c48ae9$fd152150$650a10ac@XPBL2> <412D0616.3050908@tonybibbs.com> <8319e2d604082609265437a503@mail.gmail.com> <412E432E.20206@tonybibbs.com> Message-ID: <017301c48baf$d3727d90$650a10ac@XPBL2> Sounds good - thanks Tony. I can provide credit card or transfer payment to them or you via paypal. Regards, Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Thursday, August 26, 2004 4:08 PM Subject: Re: [geeklog-devel] Update on Zend Licenses... Ok, I've confirmed that I can get the license for $100. I need confirmation from anybody interested in buying a license. In the meantime I'll check with the sales guy to see how we can handle payment (i.e. all at once vs. individually) and how I can ensure your names get put on your individual license. --Tony Vincent Furia wrote: >I might be interested as well, I want to play around with the free >version a bit more first though. > >-Vinny > >On Wed, 25 Aug 2004 16:35:18 -0500, Tony Bibbs wrote: > > >>I'll give the guy a call tomorrow and see if I can talk him down to $100. >> >>--Tony >> >> >> >>Blaine Lang wrote: >> >> >> >>>I think that I'd be interested in the Zend IDE at that price? >>> >>>Blaine >>>----- Original Message ----- >>>From: "Tony Bibbs" >>>To: >>>Sent: Wednesday, August 25, 2004 2:12 PM >>>Subject: [geeklog-devel] Update on Zend Licenses... >>> >>> >>>In working with the Zend sales guy, he'd be willing to sell copies of >>>Zend Studio for $125. I personally think we could get him down to >>>$100. Anybody willing to pay that much for licenses? >>> >>>--Tony >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From dirk at haun-online.de Sun Aug 29 14:50:45 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 29 Aug 2004 20:50:45 +0200 Subject: [geeklog-devel] Editable story IDs Message-ID: <20040829195045.28096@smtp.haun-online.de> Gentlemen, I've just made the changes so that you can now edit story IDs. When you update from CVS, please make sure to update your story editor template file. Prepare for problems, as there may be places where the story ID is not properly quoted when doing SQL requests (I already found one such case in admin/story.php). Heavy testing and feedback welcome ... bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From tomw at pigstye.net Mon Aug 30 10:10:33 2004 From: tomw at pigstye.net (Tom Willett) Date: Mon, 30 Aug 2004 14:10:33 +0000 Subject: [geeklog-devel] Comment Oddity Message-ID: <20040830135636.M957@pigstye.net> One of my sites recently began not showing comments for anonymous users, but it would show comments for registered users. I finally found that somehow the anonymous user got deleted from the user table. This was causing no comments to be returned since a valid user was required from the user table. How the anonymous user got deleted I do not know Geeklog version 1.3.9sr1 -- Tom Willett tomw at pigstye.net