From vmf at abtech.org Sun Nov 2 21:03:15 2003 From: vmf at abtech.org (Vincent Furia) Date: Sun, 02 Nov 2003 21:03:15 -0500 Subject: [geeklog-devel] Quick overview of GL2 and what we have so far and how it relates to the API In-Reply-To: <3FA2DCD4.6070207@tonybibbs.com> References: <3FA04559.5080004@tonybibbs.com> <3FA2BB66.6040505@abtech.org> <3FA2DCD4.6070207@tonybibbs.com> Message-ID: <3FA5B763.5050700@abtech.org> My idea was to store who registered which events in the database. But, thinking ahead, since event registration is not a frequent task (and therefore the table won't be changing all that much) I think we could easily use a php file as a cache. The php file would get updated everytime the event_handler table was altered. This would prevent unnecessary database calls. The cache file could look something like: And then once this file is loaded, and GL2 core gets notified of an event, all it has to do is: foreach ($eventListener[$plugin][$event] as $plugs) { require_once($plugs . '/functions.inc'); // or whatever file... $plugs::onEvent($plugin, $event, $vars); } The only problem I see with the method you suggest is that every plugin's functions.inc file (or whatever the equivilent we will use in GL2) will have to be loaded whenever any event occurs. The method recommended above, would only need to load the plugins that are listening for an event. Since I expect many more events to occur than are actually going to be handled by the different plugins, this will probably end up saving CPU and Memmory usage. It will allow us to stick with the MVCnPHP mantra of loading only what is necessary. -Vinny Tony Bibbs wrote: > I need more time to digest this but one quick note about your approach > to event handling. If I read it right, your method requires trip(s) > to the database to be able to determine which modules wanted to be > triggered when an event occurs. I would like to see us implement this > in a way that would avoid that overhead and I think we can do it. For > example, a module will know when it is shipped which modules it will > try to interact with. Here is a snippet that I think can handle this: > > /** > * This calls an event on any module > * > * NOTE: this is just a stub in the API > * > * @param string $eventName Name of the event that was fired > * @param string $module Name of the module that triggered an event > * @param array $args Array of arguments for the handler > * > */ > function handleEvent($eventName, $module, $args) > { > } > > For example purposes let's assume the following is the API > implementation of the function above for the forum module: > > /** > * Proxies events to the appropriate non-API event handlers > * > * > * @param string $eventName Name of the event that was fired > * @param string $module Name of the module that triggered an event > * @param array $args Array of arguments for the handler > * > */ > function handleEvent($eventName, $module, $args) > { > switch ($module) { > 'Geeklog': > // Call local non-API method to handle Messaging event > return handleGeeklogEvent($eventName); > 'Messaging': > // Call local non-API method to handle Messaging event > return handleMessagingEvent($eventName); > 'Stories': > // Call local non-API method to handle Story event > return handleStoryEvent($eventName); > default: > // For all other modules we don't care so bail > return false; > } > } > > Though you can see the trend, here is what you would have in one of > the event handlers. Let's assume this is the forum's event handler > for messaging: > > function handleMessagingEvent($eventName) > { > switch ($eventName) { > 'onPMSent': > return ForumEventHandler::hand > EventHandler:: > } > > In this way you don't need to register events in a database. You may > be able to condense this a bit by using is_callable() or > method_exists() to avoid too many levels of event handling proxies but > this demonstrates my idea. Again, I think we should trim GL2 down to > essential DB calls and if we can avoid them here I'd like to. I'm > sure there may be arguments for doing it in the DB which is fine, just > let me know what they are (i.e. I'm not married to any decision yet). > > Thoughts or concerns? > > --Tony > > Vincent Furia wrote: > >> A couple comments I wanted to add about plugins and other GL2 stuff. >> First, I think that we should consider making some of the 'core' >> functionality into plugins instead. Specifically I'm referring to the >> comment engine, the (potential) ratings engine, and the messaging >> system (maybe even the logging system?). This would allow users to >> replace the functionality provided by these plugins. A good example >> of this might be replacing a standard comment system with a >> forum-like comment system. I think doing so would give GL2 even more >> flexibility. >> >> I know Tony didn't mean the core feautre list to be exhaustive, but >> one item I didn't see (but would like to see) was a configuration >> utility. I think, with GL2, we should get away from forcing GL >> administrators from editing config.php by hand and move to a fully >> web based configuration utility that can be used by the plugins as >> well being used for core feautres. >> >> On that subject I think it's time to start putting together a >> document that shows what core functionality GL2 will provide and any >> information we have on how it will provide that. Something like a >> design document. It's something that I'd be willing to work on, but >> I'd need a lot of information and support, especially from Tony. >> Maybe this is something that would best be done in a Wiki format? >> >> Finally, I have a few comments about event handling system and a few >> comments on plugins in general. If we do this well, and efficiently, >> we could have a really flexible, extensible system that will beat out >> every other open source system I've seen. For that reason I think >> its important to focus, briefly on how the plugin event calls might >> work in GL2. This is just a rough idea, and I'd really like to see >> input on what you all think of this. >> >> Each plugin should be able to register the fact it wants to be called >> when certain events occur: >> registerEventCallback(plugin registering callback, plugin raising >> event, event) >> >> Then, a plugin can notify GL2 that event has occurred with: >> raiseEvent(plugin raising event, event, parameters) // >> parameters: array of values >> >> Upon being notified that an event occurred, GL2 can call the plugin >> API for all plugins registered to recieve the event: >> onEvent(plugin raising event, event, parameters) >> >> Also plugins need to be able to invoke an event/function in another >> plugin: >> invokeEvent(plugin providing function, event, parameters) >> >> I'm still thinking about possible ways raiseEvent and invokeEvent can >> handle returned values. One possibility, at least for invokeEvent, is >> the functions could be required to return a small object containing >> status (-1, failure; 0, plugin function not found; 1, success; etc.) >> and the results of the call: >> $P = invokeEvent(plugin, event, parameters); >> if ($P->status > 0) { >> echo $P->result; >> } >> >> Of course all this leads to a question if we should have a severely >> simplified API where even core functionality such as the moderation >> fuctions, comment functions, etc should all be called through this >> event API (with a plugin name = 'core'). One advantage to doing it >> this way would allow us to extend plugin functionality in later >> releases without affecting the plugin API (which would prevent plugin >> obsolesence to an extent). >> >> Another issue I think we should start talking about is plugin >> dependency, and how to handle it gracefully. Obviously plugins will >> support, to one extent or another, the use of other plugins. This >> could run the gambit from a plugin being dependent on another plugin >> to work, to a plugin using another plugin in a non dependent way >> (i.e. the plugin isn't required for operation, just for extended >> functionality). >> >> I think that is more than enough to digest in one sitting. If anyone >> would like to chat with me I'll try to be available in #geeklog. Of >> couse, email discourse is always welcome as well. >> >> -Vinny >> Who is already having fun... >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Mon Nov 3 10:45:44 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 03 Nov 2003 09:45:44 -0600 Subject: [geeklog-devel] Quick overview of GL2 and what we have so far and how it relates to the API In-Reply-To: <3FA5B763.5050700@abtech.org> References: <3FA04559.5080004@tonybibbs.com> <3FA2BB66.6040505@abtech.org> <3FA2DCD4.6070207@tonybibbs.com> <3FA5B763.5050700@abtech.org> Message-ID: <3FA67828.7070708@tonybibbs.com> Yeah, but if you start depending on files then it makes having GL2 work on multiple webservers more difficult. Let me think about this some more. --Tony Vincent Furia wrote: > My idea was to store who registered which events in the database. But, > thinking ahead, since event registration is not a frequent task (and > therefore the table won't be changing all that much) I think we could > easily use a php file as a cache. The php file would get updated > everytime the event_handler table was altered. This would prevent > unnecessary database calls. > > The cache file could look something like: > $eventListener['plugin']['event'][] = 'listening plugin'; > ?> > > And then once this file is loaded, and GL2 core gets notified of an > event, all it has to do is: > foreach ($eventListener[$plugin][$event] as $plugs) { > require_once($plugs . '/functions.inc'); // or whatever file... > $plugs::onEvent($plugin, $event, $vars); > } > > The only problem I see with the method you suggest is that every > plugin's functions.inc file (or whatever the equivilent we will use in > GL2) will have to be loaded whenever any event occurs. The method > recommended above, would only need to load the plugins that are > listening for an event. Since I expect many more events to occur than > are actually going to be handled by the different plugins, this will > probably end up saving CPU and Memmory usage. It will allow us to stick > with the MVCnPHP mantra of loading only what is necessary. > > -Vinny > > Tony Bibbs wrote: > >> I need more time to digest this but one quick note about your approach >> to event handling. If I read it right, your method requires trip(s) >> to the database to be able to determine which modules wanted to be >> triggered when an event occurs. I would like to see us implement this >> in a way that would avoid that overhead and I think we can do it. For >> example, a module will know when it is shipped which modules it will >> try to interact with. Here is a snippet that I think can handle this: >> >> /** >> * This calls an event on any module >> * >> * NOTE: this is just a stub in the API >> * >> * @param string $eventName Name of the event that was fired >> * @param string $module Name of the module that triggered an event >> * @param array $args Array of arguments for the handler >> * >> */ >> function handleEvent($eventName, $module, $args) >> { >> } >> >> For example purposes let's assume the following is the API >> implementation of the function above for the forum module: >> >> /** >> * Proxies events to the appropriate non-API event handlers >> * >> * >> * @param string $eventName Name of the event that was fired >> * @param string $module Name of the module that triggered an event >> * @param array $args Array of arguments for the handler >> * >> */ >> function handleEvent($eventName, $module, $args) >> { >> switch ($module) { >> 'Geeklog': >> // Call local non-API method to handle Messaging event >> return handleGeeklogEvent($eventName); >> 'Messaging': >> // Call local non-API method to handle Messaging event >> return handleMessagingEvent($eventName); >> 'Stories': >> // Call local non-API method to handle Story event >> return handleStoryEvent($eventName); >> default: >> // For all other modules we don't care so bail >> return false; >> } >> } >> >> Though you can see the trend, here is what you would have in one of >> the event handlers. Let's assume this is the forum's event handler >> for messaging: >> >> function handleMessagingEvent($eventName) >> { >> switch ($eventName) { >> 'onPMSent': >> return ForumEventHandler::hand >> EventHandler:: >> } >> >> In this way you don't need to register events in a database. You may >> be able to condense this a bit by using is_callable() or >> method_exists() to avoid too many levels of event handling proxies but >> this demonstrates my idea. Again, I think we should trim GL2 down to >> essential DB calls and if we can avoid them here I'd like to. I'm >> sure there may be arguments for doing it in the DB which is fine, just >> let me know what they are (i.e. I'm not married to any decision yet). >> >> Thoughts or concerns? >> >> --Tony >> >> Vincent Furia wrote: >> >>> A couple comments I wanted to add about plugins and other GL2 stuff. >>> First, I think that we should consider making some of the 'core' >>> functionality into plugins instead. Specifically I'm referring to the >>> comment engine, the (potential) ratings engine, and the messaging >>> system (maybe even the logging system?). This would allow users to >>> replace the functionality provided by these plugins. A good example >>> of this might be replacing a standard comment system with a >>> forum-like comment system. I think doing so would give GL2 even more >>> flexibility. >>> >>> I know Tony didn't mean the core feautre list to be exhaustive, but >>> one item I didn't see (but would like to see) was a configuration >>> utility. I think, with GL2, we should get away from forcing GL >>> administrators from editing config.php by hand and move to a fully >>> web based configuration utility that can be used by the plugins as >>> well being used for core feautres. >>> >>> On that subject I think it's time to start putting together a >>> document that shows what core functionality GL2 will provide and any >>> information we have on how it will provide that. Something like a >>> design document. It's something that I'd be willing to work on, but >>> I'd need a lot of information and support, especially from Tony. >>> Maybe this is something that would best be done in a Wiki format? >>> >>> Finally, I have a few comments about event handling system and a few >>> comments on plugins in general. If we do this well, and efficiently, >>> we could have a really flexible, extensible system that will beat out >>> every other open source system I've seen. For that reason I think >>> its important to focus, briefly on how the plugin event calls might >>> work in GL2. This is just a rough idea, and I'd really like to see >>> input on what you all think of this. >>> >>> Each plugin should be able to register the fact it wants to be called >>> when certain events occur: >>> registerEventCallback(plugin registering callback, plugin raising >>> event, event) >>> >>> Then, a plugin can notify GL2 that event has occurred with: >>> raiseEvent(plugin raising event, event, parameters) // >>> parameters: array of values >>> >>> Upon being notified that an event occurred, GL2 can call the plugin >>> API for all plugins registered to recieve the event: >>> onEvent(plugin raising event, event, parameters) >>> >>> Also plugins need to be able to invoke an event/function in another >>> plugin: >>> invokeEvent(plugin providing function, event, parameters) >>> >>> I'm still thinking about possible ways raiseEvent and invokeEvent can >>> handle returned values. One possibility, at least for invokeEvent, is >>> the functions could be required to return a small object containing >>> status (-1, failure; 0, plugin function not found; 1, success; etc.) >>> and the results of the call: >>> $P = invokeEvent(plugin, event, parameters); >>> if ($P->status > 0) { >>> echo $P->result; >>> } >>> >>> Of course all this leads to a question if we should have a severely >>> simplified API where even core functionality such as the moderation >>> fuctions, comment functions, etc should all be called through this >>> event API (with a plugin name = 'core'). One advantage to doing it >>> this way would allow us to extend plugin functionality in later >>> releases without affecting the plugin API (which would prevent plugin >>> obsolesence to an extent). >>> >>> Another issue I think we should start talking about is plugin >>> dependency, and how to handle it gracefully. Obviously plugins will >>> support, to one extent or another, the use of other plugins. This >>> could run the gambit from a plugin being dependent on another plugin >>> to work, to a plugin using another plugin in a non dependent way >>> (i.e. the plugin isn't required for operation, just for extended >>> functionality). >>> >>> I think that is more than enough to digest in one sitting. If anyone >>> would like to chat with me I'll try to be available in #geeklog. Of >>> couse, email discourse is always welcome as well. >>> >>> -Vinny >>> Who is already having fun... >>> >>> _______________________________________________ >>> 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 -- +----------------------------------------------------------------------+ |Tony Bibbs |[R]egardless of what you may think of our penal | |tony at tonybibbs.com |system, the fact is that every man in jail is one | | |less potential fisherman to clutter up your | | |favorite pool or pond. --Ed Zern | +----------------------------------------------------------------------+ From tony at tonybibbs.com Wed Nov 5 09:17:19 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Nov 2003 08:17:19 -0600 Subject: [geeklog-devel] [Fwd: Geeklog] Message-ID: <3FA9066F.4020906@tonybibbs.com> Guys, check this message. The long and short of it is they will be able to give us a couple of resources to help with Geeklog. Obviously their focus will be on their immediate needs but where we can we should get them involved in our efforts. Dirk, naturally you are still the man with 1.3.x so if you have a wish list for the next GL release we should dust it off and be ready to assign tasks. I'll forward our conversations prior to this message to keep you guys up-to-date. --Tony -------- Original Message -------- Subject: Geeklog Date: Tue, 4 Nov 2003 21:02:12 -0500 From: Josh Sahrmann Organization: Frontline Analytics To: Tony, We have scrapped development of our websites using MovableType and have put our full support behind Geeklog and Geeklog 2. Obviously, this is a setback in development for us, but we are excited to start working with your team and hopefully start improving the system in whatever ways possible. I will be working with my group to make sure their efforts in Geeklog move smoothly for our transition and start ramping up the possibility of working on future development of Geeklog 2. Hopefully we will be able to share whatever resources we have, and I will be sure to work with my team and begin a detailed process of documenting as much as possible for the community. Our biggest challenge right now is to ensure that there are permissions, and implementing them for our system. Hopefully by next week we will have a better idea of where we stand. In the mean time, please let me know what areas you need help with and where we might work together. Please feel free to either e-mail me, call at the number below or IM me on AIM at Spddst. I am available throughout the day and into the evening. I look forward to working with you and your group to establish a strong product. Sincerely, Josh Sahrmann 617-407-5587 From dirk at haun-online.de Wed Nov 5 14:41:46 2003 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 5 Nov 2003 20:41:46 +0100 Subject: [geeklog-devel] [Fwd: Geeklog] In-Reply-To: <3FA9066F.4020906@tonybibbs.com> References: <3FA9066F.4020906@tonybibbs.com> Message-ID: <20031105194146.11403@smtp.haun-online.de> Tony wrote: >Guys, check this message. The long and short of it is they will be able >to give us a couple of resources to help with Geeklog. Cool. >Dirk, naturally you are still the man >with 1.3.x so if you have a wish list for the next GL release we should >dust it off and be ready to assign tasks. Well, 1.3.9 is more or less feature-complete. It needs some work on filtering SQL injection attempts and lots and lots of testing. Also, a good look through the list of open bugs can't hurt. I doubt that they can help with these, so we'll have to look for work to be done after the 1.3.9 release. I've outlined 3 tasks here, which are also pretty much self-contained: #1 (cleaning up the upload class) would improve maintainability (and troubleshooting) a lot. #2 (parsing RSS and future feed formats) will also help with maintainability and extensibility (in case the Atom format catches on, we will need a parser for it and integrating it into the current code could become, erm, interesting ...). #3 (Daily Digest) - it seems that the Daily Digest feature is quite popular but it eats a lot of CPU time and runs into timeouts in hosted environments pretty quickly. The task is to look for alternatives and/or improve the current solution. I have some more that I would need to flesh out. And there's always in case they want to pick their own tasks. The question is, however, how much of that workforce do we want to direct at 1.3.x and wouldn't it be better to get them to help on GL2? On the other hand, they probably have the same problem that lets me spend so much time on 1.3 - we have sites running and need this and that feature NOW and not at some (possibly far-away) point in the future ... bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From geeklog at langfamily.ca Wed Nov 5 16:40:32 2003 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 5 Nov 2003 16:40:32 -0500 Subject: [geeklog-devel] [Fwd: Geeklog] References: <3FA9066F.4020906@tonybibbs.com> <20031105194146.11403@smtp.haun-online.de> Message-ID: <009c01c3a3e5$70acb1b0$9a0a10ac@xpbl1> It will be interesting to see what features they need to add. We should probally brainstorm about 1.4 features. Regarding 1.3.9. I have a little bit left to do on the new block admin code that will also us to move blocks up/down and left/right from the block listing. Blaine ----- Original Message ----- From: "Dirk Haun" To: Sent: Wednesday, November 05, 2003 2:41 PM Subject: Re: [geeklog-devel] [Fwd: Geeklog] > Tony wrote: > > >Guys, check this message. The long and short of it is they will be able > >to give us a couple of resources to help with Geeklog. > > Cool. > > > >Dirk, naturally you are still the man > >with 1.3.x so if you have a wish list for the next GL release we should > >dust it off and be ready to assign tasks. > > Well, 1.3.9 is more or less feature-complete. It needs some work on > filtering SQL injection attempts and lots and lots of testing. Also, a > good look through the list of open bugs can't hurt. > > I doubt that they can help with these, so we'll have to look for work to > be done after the 1.3.9 release. > > > I've outlined 3 tasks here, which are also pretty much self-contained: > > 000299.html> > > #1 (cleaning up the upload class) would improve maintainability (and > troubleshooting) a lot. > > #2 (parsing RSS and future feed formats) will also help with > maintainability and extensibility (in case the Atom format catches on, we > will need a parser for it and integrating it into the current code could > become, erm, interesting ...). > > #3 (Daily Digest) - it seems that the Daily Digest feature is quite > popular but it eats a lot of CPU time and runs into timeouts in hosted > environments pretty quickly. The task is to look for alternatives and/or > improve the current solution. > > I have some more that I would need to flesh out. And there's always > in case they > want to pick their own tasks. > > > The question is, however, how much of that workforce do we want to direct > at 1.3.x and wouldn't it be better to get them to help on GL2? On the > other hand, they probably have the same problem that lets me spend so > much time on 1.3 - we have sites running and need this and that feature > NOW and not at some (possibly far-away) point in the future ... > > 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 Nov 5 17:08:40 2003 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 5 Nov 2003 23:08:40 +0100 Subject: [geeklog-devel] [Fwd: Geeklog] In-Reply-To: <009c01c3a3e5$70acb1b0$9a0a10ac@xpbl1> References: <009c01c3a3e5$70acb1b0$9a0a10ac@xpbl1> Message-ID: <20031105220840.19067@smtp.haun-online.de> Blaine wrote: >We should probally brainstorm about 1.4 features. 1.3.10 - I don't really want to edit all the documents again. Let's see if we can catch up with Apache (currently at 1.3.29 ;-) bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From tony at tonybibbs.com Wed Nov 5 21:10:23 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 05 Nov 2003 20:10:23 -0600 Subject: [geeklog-devel] kudos Message-ID: <3FA9AD8F.6090700@tonybibbs.com> FWIW, kudos to Dirk. I just had my first article with a photo on Iowa Outdoors that forced an autmatic thumbnail that is clickable. Excellent, looks professional and lets people blow up the image (something I have always wanted). -- +-------------------+--------------------------------------------------+ |Tony Bibbs |[R]egardless of what you may think of our penal | |tony at tonybibbs.com |system, the fact is that every man in jail is one | | |less potential fisherman to clutter up your | | |favorite pool or pond. --Ed Zern | +-------------------+--------------------------------------------------+ From dirk at haun-online.de Thu Nov 6 01:58:36 2003 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 6 Nov 2003 07:58:36 +0100 Subject: [geeklog-devel] kudos In-Reply-To: <3FA9AD8F.6090700@tonybibbs.com> References: <3FA9AD8F.6090700@tonybibbs.com> Message-ID: <20031106065836.3864@smtp.haun-online.de> Tony wrote: >FWIW, kudos to Dirk. I just had my first article with a photo on Iowa >Outdoors that forced an autmatic thumbnail that is clickable. Actually, kudos should go to Alexander Schmacks who contributed this code. bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From dwight at trumbower.com Thu Nov 6 02:03:58 2003 From: dwight at trumbower.com (Dwight Trumbower) Date: Thu, 06 Nov 2003 01:03:58 -0600 Subject: [geeklog-devel] kudos In-Reply-To: <3FA9AD8F.6090700@tonybibbs.com> References: <3FA9AD8F.6090700@tonybibbs.com> Message-ID: <6.0.0.22.0.20031106010317.01d25940@localhost> At 08:10 PM 11/5/2003, you wrote: >FWIW, kudos to Dirk. I just had my first article with a photo on Iowa >Outdoors that forced an autmatic thumbnail that is clickable. Excellent, >looks professional and lets people blow up the image (something I have >always wanted). Ok, so where is the link so we can take a look? Dwight From tony at tonybibbs.com Thu Nov 6 09:23:42 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 06 Nov 2003 08:23:42 -0600 Subject: [geeklog-devel] kudos In-Reply-To: <6.0.0.22.0.20031106010317.01d25940@localhost> References: <3FA9AD8F.6090700@tonybibbs.com> <6.0.0.22.0.20031106010317.01d25940@localhost> Message-ID: <3FAA596E.3010405@tonybibbs.com> http://www.iowaoutdoors.org/ Second story down. --Tony Dwight Trumbower wrote: > At 08:10 PM 11/5/2003, you wrote: > >> FWIW, kudos to Dirk. I just had my first article with a photo on Iowa >> Outdoors that forced an autmatic thumbnail that is clickable. >> Excellent, looks professional and lets people blow up the image >> (something I have always wanted). > > > Ok, so where is the link so we can take a look? > > Dwight From tony at tonybibbs.com Thu Nov 6 16:05:40 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 06 Nov 2003 15:05:40 -0600 Subject: [geeklog-devel] Interesting concept Message-ID: <3FAAB7A4.30502@tonybibbs.com> You may have seen it already: http://invisiblog.com/ It allows for truly anonymous posting. From slord at marelina.com Thu Nov 6 16:28:00 2003 From: slord at marelina.com (Simon Lord) Date: Thu, 6 Nov 2003 16:28:00 -0500 Subject: [geeklog-devel] Interesting concept In-Reply-To: <3FAAB7A4.30502@tonybibbs.com> References: <3FAAB7A4.30502@tonybibbs.com> Message-ID: <18957FE6-10A0-11D8-9C5F-003065C030F2@marelina.com> So who is liable for comments posted then? What if some goof posts the code and how to use it to decrypt DVD movies etc? I think it's very cool, but I wouldn't want to be the owner of such a site. Then, at the other end of the spectrum we have this: http://www.theregister.co.uk/content/6/33835.html On Nov 6, 2003, at 4:05 PM, Tony Bibbs wrote: > You may have seen it already: > > http://invisiblog.com/ > > It allows for truly anonymous posting. > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > Sincerely, Simon From tony at tonybibbs.com Thu Nov 6 16:45:06 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 06 Nov 2003 15:45:06 -0600 Subject: [geeklog-devel] Interesting concept In-Reply-To: <18957FE6-10A0-11D8-9C5F-003065C030F2@marelina.com> References: <3FAAB7A4.30502@tonybibbs.com> <18957FE6-10A0-11D8-9C5F-003065C030F2@marelina.com> Message-ID: <3FAAC0E2.7030604@tonybibbs.com> It's as strong as GPG encryption. We'd have to be able to break it in order to be able to say who posted something. If it is slander deemed inappropriate by law the service provider (you) could be asked to remove the offending post but you are not liable for damage done from the posts. --Tony Simon Lord wrote: > So who is liable for comments posted then? What if some goof posts the > code and how to use it to decrypt DVD movies etc? I think it's very > cool, but I wouldn't want to be the owner of such a site. > > Then, at the other end of the spectrum we have this: > > http://www.theregister.co.uk/content/6/33835.html > > > > On Nov 6, 2003, at 4:05 PM, Tony Bibbs wrote: > >> You may have seen it already: >> >> http://invisiblog.com/ >> >> It allows for truly anonymous posting. >> >> _______________________________________________ >> 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 From geeklog at langfamily.ca Thu Nov 6 20:30:28 2003 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 6 Nov 2003 20:30:28 -0500 Subject: [geeklog-devel] PostNuke's way of handling Post and Get Vars Message-ID: <00c301c3a4ce$ba30bb80$9a0a10ac@xpbl1> I have a client project that will require doing a module for PostNuke. As best I can tell - PostNuke (pn) is mostly all new code and approach from phpNuke. PostNuke is still not a 1.0 release. Latest being 0.726 Anyway - They have a very different API then ours. So far, I like what I see. Not necessarily better - just different I can send out updates of what I see and learn if this group is interested. With our recent security related issues and extra coding requried for plugin developers to handle POST and GET vars. I liked the solution PostNuke has. The following is how all variables are to be retrieved and used inside modules. It makes it easy as I've had to include functions each time and recently we determined a need for additional filtering. Blaine ---------------- Name pnVarCleanFromInput - obtain form variable Synopsis mixed pnVarCleanFromInput(name, ...); string name, , string ... ; Description pnVarCleanFromInput() takes a variable number of name arguments and for each one obtains the variable from the input namespace. It removes any preparsing done by PHP to ensure that the string is exactly as expected, without any escaped characters. pnVarCleanFromInput() also removes any HTML tags that could be considered dangerous to the PostNuke system's security. Return Values If pnVarCleanFromInput() is only passed a single name argument then it returns the corresponding variable. If pnVarCleanFromInput() is passed multiple arguments then it returns an array of corresponding variables. Notes Obtaining input variables from the global namespace, or from arrays such as HTTP_POST_VARS, is not supported and should never be done. pnVarCleanFromInput() is the only supported way of obtaining such variables. Examples // Obtain a single value $id = pnVarCleanFromInput('id'); // Obtain a number of values list($name, $number) = pnVarCleanFromInput('name', 'number'); From dirk at haun-online.de Sun Nov 9 13:10:54 2003 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 9 Nov 2003 19:10:54 +0100 Subject: [geeklog-devel] [Fwd: Geeklog] In-Reply-To: <3FA9066F.4020906@tonybibbs.com> References: <3FA9066F.4020906@tonybibbs.com> Message-ID: <20031109181054.15408@smtp.haun-online.de> Tony wrote: >so if you have a wish list for the next GL release we should >dust it off and be ready to assign tasks. Since we have GForge, we could as well use it for this: This currently defines 5 tasks for things that I'd like to see added to Geeklog at one point or another. bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From tony at tonybibbs.com Mon Nov 10 16:59:07 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 10 Nov 2003 15:59:07 -0600 Subject: [geeklog-devel] [Fwd: Geeklog] In-Reply-To: <20031109181054.15408@smtp.haun-online.de> References: <3FA9066F.4020906@tonybibbs.com> <20031109181054.15408@smtp.haun-online.de> Message-ID: <3FB00A2B.2070504@tonybibbs.com> Sounds good. I requested that he have his team join geeklog-devtalk along with a brief intro and which of the GL projects they want to help out with. I opted not to put them on the geeklog-devel so as to keep that for just core developers. If we get into it and feel they need to be added to the other list we can do so. Hopefully we'll get an email soon. --Tony Dirk Haun wrote: > Tony wrote: > > >>so if you have a wish list for the next GL release we should >>dust it off and be ready to assign tasks. > > > Since we have GForge, we could as well use it for this: > > > > This currently defines 5 tasks for things that I'd like to see added to > Geeklog at one point or another. > > bye, Dirk > > From tony at tonybibbs.com Thu Nov 13 09:37:02 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 13 Nov 2003 08:37:02 -0600 Subject: [geeklog-devel] Is this on the feature request? Message-ID: <3FB3970E.8080002@tonybibbs.com> Integrate this into Geeklog: http://www.captcha.net/ --Tony From tony at tonybibbs.com Thu Nov 13 09:40:29 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 13 Nov 2003 08:40:29 -0600 Subject: [geeklog-devel] Re: Is this on the feature request? In-Reply-To: <3FB3970E.8080002@tonybibbs.com> References: <3FB3970E.8080002@tonybibbs.com> Message-ID: <3FB397DD.40806@tonybibbs.com> Sorry, this is more on how we might integrate it: http://www.chimetv.com/tv/products/botblock.shtml If this looks familiar it's because it was ran on slashdot not too long ago. --Tony Tony Bibbs wrote: > Integrate this into Geeklog: > > http://www.captcha.net/ > > --Tony > From vmf at abtech.org Thu Nov 13 21:45:53 2003 From: vmf at abtech.org (Vincent Furia) Date: Thu, 13 Nov 2003 21:45:53 -0500 Subject: [geeklog-devel] Re: Is this on the feature request? In-Reply-To: <3FB397DD.40806@tonybibbs.com> References: <3FB3970E.8080002@tonybibbs.com> <3FB397DD.40806@tonybibbs.com> Message-ID: <3FB441E1.5090707@abtech.org> Just keep in mind people who use diability tools won't be able to "read" it either. -Vinny Tony Bibbs wrote: > Sorry, this is more on how we might integrate it: > > http://www.chimetv.com/tv/products/botblock.shtml > > If this looks familiar it's because it was ran on slashdot not too > long ago. > > --Tony > > Tony Bibbs wrote: > >> Integrate this into Geeklog: >> >> http://www.captcha.net/ >> >> --Tony >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Fri Nov 14 08:36:34 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 14 Nov 2003 07:36:34 -0600 Subject: [geeklog-devel] Re: Is this on the feature request? In-Reply-To: <3FB441E1.5090707@abtech.org> References: <3FB3970E.8080002@tonybibbs.com> <3FB397DD.40806@tonybibbs.com> <3FB441E1.5090707@abtech.org> Message-ID: <3FB4DA62.9070801@tonybibbs.com> Yeah, this would be something you would enable/disable. --Tony Vincent Furia wrote: > Just keep in mind people who use diability tools won't be able to "read" > it either. > > -Vinny > > Tony Bibbs wrote: > >> Sorry, this is more on how we might integrate it: >> >> http://www.chimetv.com/tv/products/botblock.shtml >> >> If this looks familiar it's because it was ran on slashdot not too >> long ago. >> >> --Tony >> >> Tony Bibbs wrote: >> >>> Integrate this into Geeklog: >>> >>> http://www.captcha.net/ >>> >>> --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 Sat Nov 15 11:46:07 2003 From: geeklog at langfamily.ca (Blaine Lang) Date: Sat, 15 Nov 2003 11:46:07 -0500 Subject: [geeklog-devel] Advanced Search - showing links Message-ID: <002401c3ab97$f7727270$6b1bfea9@xpbl1> Although it may not be a bug, it is annoying that Advanced Search by Author returns all the link results. The links table does not track the UID fr the user that submitted the request. What do you think about fixing this for 1.3.9 - Do we just not show the links if doing a search by author - Modify the logic and table to record the UID. Default being root for any existing link records. Blaine From dirk at haun-online.de Sat Nov 15 12:07:19 2003 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 15 Nov 2003 18:07:19 +0100 Subject: [geeklog-devel] Advanced Search - showing links In-Reply-To: <002401c3ab97$f7727270$6b1bfea9@xpbl1> References: <002401c3ab97$f7727270$6b1bfea9@xpbl1> Message-ID: <20031115170719.4598@smtp.haun-online.de> Blaine, >Although it may not be a bug, it is annoying that Advanced Search by Author >returns all the link results. Actually, it has been filed as a bug: And I agree that it's annoying. >What do you think about fixing this for 1.3.9 >- Do we just not show the links if doing a search by author >- Modify the logic and table to record the UID. Default being root for any >existing link records. Would you volunteer to make those changes? Either solution is fine with me. Actually, when the link submission queue is "off", it already tracks the uid of the submitter (i.e. the owner_id is set to the uid of the submitter). bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From geeklog at langfamily.ca Sat Nov 15 13:14:48 2003 From: geeklog at langfamily.ca (Blaine Lang) Date: Sat, 15 Nov 2003 13:14:48 -0500 Subject: [geeklog-devel] Advanced Search - showing links References: <002401c3ab97$f7727270$6b1bfea9@xpbl1> <20031115170719.4598@smtp.haun-online.de> Message-ID: <000901c3aba4$5acbae70$6b1bfea9@xpbl1> I knew that I may have been putting my hand up :P Not a problem will add that to my list. I did not know that when link submissions were disabled that it captured the UID as the ownerid. I'll first look into seeing what is invovled to capture the submitter UID and reporting/searching with this field. Not sure of the scope yet of the impacted changes. Blaine ----- Original Message ----- From: "Dirk Haun" To: Sent: Saturday, November 15, 2003 12:07 PM Subject: Re: [geeklog-devel] Advanced Search - showing links > Blaine, > > >Although it may not be a bug, it is annoying that Advanced Search by Author > >returns all the link results. > > Actually, it has been filed as a bug: > > func=detail&aid=87&group_id=6&atid=105> > > And I agree that it's annoying. > > > >What do you think about fixing this for 1.3.9 > >- Do we just not show the links if doing a search by author > >- Modify the logic and table to record the UID. Default being root for any > >existing link records. > > Would you volunteer to make those changes? > > Either solution is fine with me. Actually, when the link submission queue > is "off", it already tracks the uid of the submitter (i.e. the owner_id > is set to the uid of the submitter). > > 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 geeklog at langfamily.ca Tue Nov 18 07:24:42 2003 From: geeklog at langfamily.ca (Blaine Lang) Date: Tue, 18 Nov 2003 07:24:42 -0500 Subject: [geeklog-devel] GL API for plugin related CSS Message-ID: <000c01c3adce$f1db1180$6b1bfea9@xpbl1> How about if we added a API call to COM_SiteHeader() that would add any plugin specific CSS? We have a {plg_headercode} now in the template header.thtml for any Javascript type functions to be added automatically. We could add a {plg_csscode} in the header.thtml as well That would remove that added step and confustion about adding the new CSS to all your templates. Add your css to theme/plugin/plugin.css and have it included automatically. Blaine From tony at tonybibbs.com Thu Nov 20 17:34:30 2003 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 20 Nov 2003 16:34:30 -0600 Subject: [geeklog-devel] New member Message-ID: <3FBD4176.7060902@tonybibbs.com> Let me welcome Justin Carlson to the GL2 team. Just works with me and is a damn fine PHP coder who, from what I hear, spends way too much time playing EverQuest online and has graciously decided to help out with Geeklog 2 instead. He and I have talked and he's going to probably look at hacking the gforge bugtracker to allow for remote bug submissions and browsing using either XMLRPC or raw XML over HTTP. After that I will probably have him start in on the remote module administration stuff that JasonW started on. Jason, if you are still lurking, can you send over what code you did have done? Thanks, --Tony From geeklog at langfamily.ca Thu Nov 20 17:44:36 2003 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 20 Nov 2003 17:44:36 -0500 Subject: [geeklog-devel] New member References: <3FBD4176.7060902@tonybibbs.com> Message-ID: <040d01c3afb7$dfb2f870$6b1bfea9@xpbl1> Welcome Justin, And don't worry, you won't have to only work with Tony ;) Cheers, Blaine ----- Original Message ----- From: "Tony Bibbs" To: "Geeklog" Sent: Thursday, November 20, 2003 5:34 PM Subject: [geeklog-devel] New member > Let me welcome Justin Carlson to the GL2 team. Just works with me and > is a damn fine PHP coder who, from what I hear, spends way too much time > playing EverQuest online and has graciously decided to help out with > Geeklog 2 instead. > > He and I have talked and he's going to probably look at hacking the > gforge bugtracker to allow for remote bug submissions and browsing using > either XMLRPC or raw XML over HTTP. After that I will probably have him > start in on the remote module administration stuff that JasonW started on. > > Jason, if you are still lurking, can you send over what code you did > have done? > > Thanks, > > --Tony > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vmf at abtech.org Wed Nov 26 21:54:00 2003 From: vmf at abtech.org (Vincent Furia) Date: Wed, 26 Nov 2003 21:54:00 -0500 Subject: [geeklog-devel] Geeklog.net Down Message-ID: <3FC56748.1090703@abtech.org> Tony, Just an FYI that it looks like the database is down on http://www.geeklog.net. -Vinny From vmf at abtech.org Wed Nov 26 21:55:40 2003 From: vmf at abtech.org (Vincent Furia) Date: Wed, 26 Nov 2003 21:55:40 -0500 Subject: [geeklog-devel] Re: Geeklog.net Down In-Reply-To: <3FC56748.1090703@abtech.org> References: <3FC56748.1090703@abtech.org> Message-ID: <3FC567AC.3090809@abtech.org> Nevermind, looks like its back up now. -Vinny Vincent Furia wrote: > Tony, > > Just an FYI that it looks like the database is down on > http://www.geeklog.net. > > -Vinny > From dirk at haun-online.de Thu Nov 27 01:59:48 2003 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 27 Nov 2003 07:59:48 +0100 Subject: [geeklog-devel] Geeklog.net Down In-Reply-To: <3FC56748.1090703@abtech.org> References: <3FC56748.1090703@abtech.org> Message-ID: <20031127065948.22413@smtp.haun-online.de> Vinny, >Just an FYI that it looks like the database is down on >http://www.geeklog.net. I've seen the occassional "could not connect to MySQL" or similar over the last few days. Always came back up within minutes. I guess we should contact pair.com support and ask them what's going on ... bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From pfawcett at smx.pair.com Thu Nov 27 13:20:22 2003 From: pfawcett at smx.pair.com (Pat F) Date: Thu, 27 Nov 2003 13:20:22 -0500 (EST) Subject: [geeklog-devel] Re: [geeklog-devtalk] geeklog-devel digest, Vol 1 #230 - 3 msgs In-Reply-To: <20031127180010.25612.69630.Mailman@internal.iowaoutdoors.org> References: <20031127180010.25612.69630.Mailman@internal.iowaoutdoors.org> Message-ID: Looks like mysqld just restarted about two hours ago: root at qs457# mysqladmin status Uptime: 7342 Threads: 1 Questions: 148372 Slow queries: 0 Opens: 87 Flush tables: 1 Open tables: 80 Queries per second avg: 20.209 root at qs457# Our server monitoring will restart mysqld automatically if the process eats up too much CPU. Dirk said this has been happening the last few days... was it at the same time each day? Please send as much detailed information as you can to qs at pair.com and we can check the server logs to see what is causing the mysql restarts. Happy Thanksgiving! -Pat On Thu, 27 Nov 2003 geeklog-devel-request at lists.geeklog.net wrote: > Send geeklog-devel mailing list submissions to > geeklog-devel at lists.geeklog.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.geeklog.net/listinfo/geeklog-devel > or, via email, send a message with subject or body 'help' to > geeklog-devel-request at lists.geeklog.net > > You can reach the person managing the list at > geeklog-devel-admin at lists.geeklog.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of geeklog-devel digest..." > > > Today's Topics: > > 1. Geeklog.net Down (Vincent Furia) > 2. Re: Geeklog.net Down (Vincent Furia) > 3. Re: Geeklog.net Down (Dirk Haun) > > --__--__-- > > Message: 1 > Date: Wed, 26 Nov 2003 21:54:00 -0500 > From: Vincent Furia > To: Tony Bibbs , > Geeklog Development > Subject: [geeklog-devel] Geeklog.net Down > Reply-To: geeklog-devel at lists.geeklog.net > > Tony, > > Just an FYI that it looks like the database is down on > http://www.geeklog.net. > > -Vinny > > > --__--__-- > > Message: 2 > Date: Wed, 26 Nov 2003 21:55:40 -0500 > From: Vincent Furia > To: Tony Bibbs , > Geeklog Development > Subject: [geeklog-devel] Re: Geeklog.net Down > Reply-To: geeklog-devel at lists.geeklog.net > > Nevermind, looks like its back up now. > > -Vinny > > Vincent Furia wrote: > > > Tony, > > > > Just an FYI that it looks like the database is down on > > http://www.geeklog.net. > > > > -Vinny > > > > > > --__--__-- > > Message: 3 > From: "Dirk Haun" > To: > Subject: Re: [geeklog-devel] Geeklog.net Down > Date: Thu, 27 Nov 2003 07:59:48 +0100 > Organization: Terra Software Systems > Reply-To: geeklog-devel at lists.geeklog.net > > Vinny, > > >Just an FYI that it looks like the database is down on > >http://www.geeklog.net. > > I've seen the occassional "could not connect to MySQL" or similar over > the last few days. Always came back up within minutes. > > I guess we should contact pair.com support and ask them what's going on ... > > 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 > > > End of geeklog-devel Digest > _______________________________________________ > geeklog-devtalk mailing list > geeklog-devtalk at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devtalk > Patrick From dirk at haun-online.de Thu Nov 27 15:53:56 2003 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 27 Nov 2003 21:53:56 +0100 Subject: [geeklog-devel] Re: [geeklog-devtalk] geeklog-devel digest, Vol 1 #230 - 3 msgs In-Reply-To: References: Message-ID: <20031127205356.12822@smtp.haun-online.de> Pat, thanks for joining in. >Looks like mysqld just restarted about two hours ago: [...] >Our server monitoring will restart mysqld automatically if the process >eats up too much CPU. > >Dirk said this has been happening the last few days... was it at the same >time each day? Good question. I can't remember, but will keep an eye on it now. Today, I came across a MySQL outage at 12:30 CET - that should be 6:30 EST, if I'm not mistaken (the clock on the server is 6 hours behind my time). As I said, I'll keep an eye on it and will let you know if (and when) I come across further downtimes. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/