[geeklog-devel] Plugin help --- Package Extractor
Chris 'Chipper' Chiapusio
chipper at llamas.net
Sat Jun 16 10:56:29 EDT 2007
On Fri, Jun 15, 2007 at 12:47:01PM -0700, Tony Bibbs wrote:
I still see plugins refrence their compatability with geeklog by the geeklog
version. You might consider versioning the GeekLog PLugIn API, thought its
honestly too early for me to be posting (and i've only finished on cup of
coffee).
OK, here is where I wander into themes....
I've been a die-hard redhat/fedora user for over ten years so I don't know if
other distros do this but... for example apache. In Fedora apache reads in
all the config files named /etc/httpd/conf.d/*.conf. Themes should have a
capability API level, and a structure so the aforementioned PEAR installer
will drop the appropriate plugin theme templates into an automagicly useful
location.
I guess to tie this all together and have it make sense: Plugins and Theme
templates are in the same boat. You should be able to use them for GL 1.4,
1.5, 1.6, etc. if there has been no significant changes. Your PEAR mechanism
to retrieve plugins must chech compatability, and will that be a massive
1-to-1 GLver-to-Plugin ver list? or a GL Plugin API Ver ->Plugin List?
or will it be more granular and the plugins request explicit capabilities? I
guess the current API is not designed for that type of structure (My brain is
thinking of ESMTP at this point).
This new installer method might also work for themes, but then we need a
theme package structure that would support multiple versions/capabilities, or
a range of version/capabilities.
This has never been an issue previous because every install was manual and
humans are (usually) very good at pattern matching (Read the William Gibson
book by that name BTW) but now we are going to make it a pretty point n'
click interface and we probably dont want 17 copies of the forum plugin in a
repository so you can support GL 1.4.1, 1.4.2, 1.4.2b, ad nauseum, the
everyones filemgmt plugin has become.
Chip
> That's about all there is to it. Christian and I have already packaged up
> the core packages so it's just a matter of embedding PEAR and then doing
> whatever magic is needed to get the embedded pear.ini loaded so that PEAR
> can do it's magic (install, upgrade, remove, etc).
>
> In short, you are on the right track.
>
> --Tony
>
> ----- Original Message ----
> From: Mark R. Evans <mevans at ecsnet.com>
> To: Geeklog Development <geeklog-devel at lists.geeklog.net>
> Sent: Friday, June 15, 2007 2:12:03 PM
> Subject: Re: [geeklog-devel] Plugin help --- Package Extractor
>
> Maybe I'm over simplifying the process, but why wouldn't something like
> this work?
>
> You get Geeklog installed, everything you need for PEAR to assist in the
> plugin install is already there. I'm assuming Geeklog is still installed
> via a tarball as it is now.
>
> Once you have the foundation, using something like PEAR_Frontend_Web that
> Christian referenced, it would be as simple as the new site admin to click
> the 'Add Plugins' link under the admin menu, see a list of available
> plugins from the Geeklog PEAR Channel, select the one they want and away
> it goes.
>
> To achieve this wonderfully simple process, the following would have to
> happen:
>
> 1. Get the core PEAR stuff into Geeklog if it isn't already there.
> 2. Implement PEAR_Frontend_Web as a plugin (basically get it into
> Geeklog's Admin section)
> 3. Implement a process for us plugin writers to get our wares on the
> Geeklog PEAR Channel (or we can create our own channel if we wish).
> 4. Plugins will need to be packaged appropriately to support this
> distribution channel.
>
> So the heavy lifting is to get the web frontend integrated with Geeklog
> and get the plugin writers to create the appropriate packaging.
>
> I'm game for checking out PEAR_Frontend_Web to see just how difficult (or
> easy) this could be.
>
> So, what am I missing?
>
> Thanks!
> Mark
>
> On 6/15/07, Blaine Lang < [1]devel at portalparts.com> wrote:
>
> /me set reminder to really really look at this!
> pear install forum -- certainly sounds easy :)
>
> Tony Bibbs wrote:
> > That's my point, they don't have to setup a PEAR repository, an
> *embedded* PEAR repository would come with a core Geeklog
> setup. Frankly until somebody other than me is willing to lift the hood
> at how you might use PEAR for this instead of writing it off because
> they *think* they know how it all works, it's probably not worth
> discussing much further. I'm the first to admit that embedding PEAR is
> not typical use, that PEAR because of it's feature set it can be complex
> and requires a bit of ramp to understand but there are a lot of smart
> people on this list who no doubt could figure this out with a little
> time. If we collectively choose to ignore the possibility of using PEAR
> (which is likely based on overwhelming silence from some of the more
> noteable 1.x developers) , that's fine but I just want to be on record
> for saying as clearly as possible that PEAR
> > was built to do *exactly* what is trying to be accomplished here.
> >
> > --Tony
> >
> > ----- Original Message ----
> > From: Joe Mucchiello <[2]joe at ThrowingDice.com>
> > To: Geeklog Development < [3]geeklog-devel at lists.geeklog.net >
> > Sent: Thursday, June 14, 2007 6:57:51 PM
> > Subject: Re: [geeklog-devel] Plugin help --- Package Extractor
> >
> > At 10:06 AM 6/14/2007, you 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 ;-)
> >>
> >
> > I think explaining to folks how to setup a PEAR repository is a lot
> > harder than how to setup geeklog. And people get geeklog screwed up
> > all the time. I doubt you read the installation help forums at
> > [4]geeklog.net but everyday someone else needs help. Dirk directs them
> > to a couple FAQs and then the next day they're posting the path/url
> > section of their config.php so we can understand just what they've
> > screwed up because even with a bunch very straightforward directions
> > and faqs, people don't get it right. Once my plugin is working well,
> > I would hope it would get into the core because installing plugins is
> > the next big headache.
> >
> > The core problem is people who do not understand the difference among
> > files, directory paths and urls are the target audience for CMS
> > software. Anything we can do to make that easier for the devs to
> > support helps. Also, remember, there is no reason why there can't be
> > both my plugin and the PEAR channels. If the PEAR channel were
> > completed, my plugin could hook into it too. Remember I'm writing
> > this as a device to reduce the amount of support requests on the
> > website. I don't know if I'll succeed, but I think a targeted
> > solution will work better than just throwing PEAR at the problem.
> >
> > ----
> > Joe Mucchiello
> > Throwing Dice Games
> > [5]http://www.throwingdice.com
> >
--
------
**** Warning ****
This e-mail message, without warrant or warning, and despite US law as set
forth in the Foreign Intelligence Surveillance Act of 1978, may be subject
to monitoring by the United States National Security Agency and/or the
Department of Defense. Information contained in this message may be used
against any senders or recipients, now or in the future, in a public trial
or secret tribunal.
Please encrypt anything important.
PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D
More information about the geeklog-devel
mailing list