[geeklog-devel] Plugin help --- Package Extractor

Thu Jun 14 10:32:10 EDT 2007

I agree with Tony, you shouldn't have to reinvent the wheel. Code reuse is a 
big part of programming and what PEAR does is the wheel. Modifications to the 
wheel are fine even great, make the wheel rounder, cleaner, faster. I am a 
firm believer in code reuse. 

On Thursday 14 June 2007 10:06 am, Tony Bibbs wrote:
> Joe, while all this sounds good, it duplicates everything PEAR does.  Just
> a note you can do all this stuff with an embedded PEAR installation (read:
> no dependency on a system-level PEAR installation).  While people are
> trying out Joe's code (which is good) I'd wish people would do more than
> just stare blindly at the PEAR stuff committed months ago.  A little TLC
> and it will do everything Joe's trying to do minus having to manage the
> core code that manages packages, etc.
>
> Feel free to drop this note in the Trash folder, but figured i'd remind
> everybody this sort of stuff is there in a way that is a lot less work us. 
> Not that I'm bitter ;-)
>
> --Tony
>
> ----- Original Message ----
> From: Joe Mucchiello <joe at ThrowingDice.com>
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Sent: Tuesday, June 12, 2007 9:26:51 PM
> Subject: [geeklog-devel] Plugin help --- Package Extractor
>
> I've just about finished a new plugin called Package Extractor for
> Geeklog. I consider it only Alpha level code at the moment. In a
> nutshell, it presents an upload form for plugin tarballs. You upload
> the tarball and it extracts the files to the proper directories
> (admin to /public_html/admin/plugins/$plugin_name, public_html to
> /public_html/plugins/$plugin_name, and the rest to
> /plugins/$plugin_name). Assuming nothing goes wrong it redirects you
> to the plugin.php where the install link for the new plugin should be
> available in lower part of the page.
>
> Features (and Limitations):
> * Appears on the Admin menu only to members of Root as "Package
> Extractor (N/A)".
> * It only works with tar, tar.gz, tar.bz2 and tgz files as it is
> using PEAR::ARCHIVE::TAR to do the extractions. Plans for zip and rar
> support as they become available.
> * Likewise, it is pretty strict about the file name being
> $plugin_$plver_$glver.tar.
> * If there is a file named package.inc in the tarball, it will
> attempt to execute the function plugin_postpackageupload_$plugin (if
> it exists) after it moves the files. This is a place where plugins
> with weird file location requirements can move more stuff around.
> (Like Blaine's lib-portalparts.php file.) If the function returns
> false, the upload is aborted (though I still need to make it clean up.
> * Each major step of the process executes in its own request using
> redirects to avoid long processing time limitations made by some webhosts.
> * Files are placed in /data/packages before extraction. On success
> they are moved to /data/packages/installed. (Automatic cleanup of
> installed is a future feature.)
> * If the plugin is already installed, it compares plugin versions. If
> they match, it aborts the extraction. If they don't match it disables
> the current plugin, extracts and re-enables. This should activate the
> "upgrade" button in the plugins.php admin screen.
> * It logs much of its activity to a file called /logs/package.log
>
> Future Ideas:
> * Well, some kind of
> SOAP/XML-RPC/Web20/whatever-it's-called-these-days interface to a
> public website which would allow you to download the package from the
> web rather than uploading from the browser would be really cool.
> Probably include a support URL API like plugin_support_site_$plugin
> so plugins can reveal their "official" website to the package
> extractor (this would go in functions.inc of course).
> * It's called Package Extractor because I expect it to also work with
> Theme installation someday.
> * package.inc could have lots of cool functions. Like,
> plugin_final_instructions_$plugin, a function that would display an
> informative page about last minute things you MUST take care before
> hitting that install link. It would end on that page instead of
> plugins.php page if the function returns a string. Or,
> plugin_home_server_$plugin which, with the web20 interface could
> allow the plugin to verify it is up to date.
> * Oh, yeah. It needs a good icon.
>
> As I said, it's at the Alpha stage. It works in my test environment
> for most simple plugins (autotags, nettools, faq, glutil). More
> complex plugins really need that package.inc file but that's up to
> the plugin writers to support. And that's why I'm posting here. This
> thing needs testing in alternate environments (I've only got Win XP,
> Apache 2, PHP 5, GL 1.4.1). I'm looking for a few testers and for a
> few plugin writers to support the package.inc extensions.
>
> I'll have a tarball available to those who request it by the end of
> the week (although originally I was going to post this Sunday so who
> knows). I just need to test installing the package extractor plugin
> itself as it's been an active plugin in my test system for a while
> now. I also need to make a sample package.inc file.
>
>
> ----
> Joe Mucchiello
> Throwing Dice Games
> http://www.throwingdice.com
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel

-- 
Best Regards,
Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20070614/b67bce16/attachment.sig>