Spartacus as pear channel

Creating and modifying plugins.
Post Reply
MySchizoBuddy
Regular
Posts: 340
Joined: Sun Jun 12, 2005 5:28 am

Spartacus as pear channel

Post by MySchizoBuddy »

I have been working on making spartacus into a pear channel so it works just like pear.php.net does. right now it works under my localserver.

First i would like to thank Gregory Beaver of the Chiara String Quartet for helping me every step of the way. he has been really patience with me :) He is the Lead developer of Chiara Pear Server and Pear 1.4 package.

OK here is how it will/should work
Server side
Use to upload, maintain and surf for plugins and templates.
--Backend available to developers only (using Chiara Pear Server)
Image
Image

--Frontend used by users (using Crtx_PEAR_Channel_Frontend)
Image
Image
Image
Image

now lets talk about How you can install packages (plugins and templates)

Client Side
This will have to be incorporated inside s9y
1) install using pear binary by using the following syntax

Code: Select all

pear install Spartacus/package_name
2)Use Pear frontend Web which should look something liek this. I still haven't gotten it to display spartacus packages. So this is just a sample of how it will look
Image

Want to help
--Chiara backend and Crtx frontend are both in alpha release. It would be nice if some of us can help em out out and finish it. :) Greg helped me get so far. and it would be nice if someone of us can help them as well. I would like the ability to attach images to packages. usefull when installing templates.
--Pear frontend Web. The developers of this package have no desire to maintain this or upgrade this to support pear 1.4. the frontend package hasn't been updated in more than a year.

ToDo
-- Figure out how to make Pear FrontendWeb to only show packages from spartacus and not from pear.php.net
--Figure out how to install pear packages inside Bundled-libs folder inside serendipity. but packages from Spartacus should install inside the plugins/templates folder. Basically the ability to install packages whereever i want.
--A package converter has to be written that will convert Spartacus.xml to package.xml. preferably a web based.
--Find out how to extract information from the plugins themselves so package.xml file doesn't have to be manually created.
--How to make it create database tables. Plugins like Karma plugins add additional tables. This is possible by running

Code: Select all

pear run-scripts Spartacus/Karma_Voting
. will have to look into it.

I'll add more things as i think of them. untill then feel free to comment on it.
Image
dma147
Regular
Posts: 132
Joined: Thu Sep 08, 2005 1:50 pm
Location: Berlin
Contact:

Post by dma147 »

Hi...

That really looks amazing...
But I really could not get the sense behind this all?
Is it for developing new s9y-plugins, like we do it until now through CVS? Or should this only be for s9y-users to download and install s9y plugins?
Or maybe both?
And why this new way then? Isn't it enough how it is done until now?

Don't see this as critism, I only want to understand this. ;)
Alexander Mieland, dma147
http://blog.linux-stats.org
CelloG
Posts: 1
Joined: Mon Oct 10, 2005 6:58 pm

PEAR_Frontend_Web

Post by CelloG »

Hi,


I actually spent a while updating PEAR_Frontend_Web to work with channels, the source is available at cvs.php.net/pear/PEAR_Frontend_Web.

The maintainers have not released it. Those of you who might remember the Date package, which was developed by the same people. For about a year and a half, the most recent version was missing a file and so would not install properly. Same issues here :)

However, the web frontend has a major issue - it does not set permissions so that the normal user can erase/modify installed files. There is one way to fix this (have an option to set files world-writeable on install), but I'm not sure about its security as a generic solution.

As for why to do this, using a tried and proven installation method will have serious benefit to s9y developers and users. For instance:

1) it will not limit serendipity plugins to spartacus

developers could serve non-official plugins from their own channel, which could then be moved to spartacus when the time is right. This would be good for license conflicts, for instance

2) s9y core devs will not need to maintain/debug the installation code.

I just tried to install a plugin and got:

Trying to open URL http://netmirror.org/mirror/serendipity ... idebar.xml...


Trying to open URL http://cvs.sourceforge.net/viewcvs.py/* ... additional......
The URL http://cvs.sourceforge.net/viewcvs.py/* ... rev=1.9999 could not be opened. Maybe the Serendipity or SourceForge.net Server is down - we are sorry, you need to try again later.Trying to open URL http://cvs.sourceforge.net/viewcvs.py/* ... additional......
The URL http://cvs.sourceforge.net/viewcvs.py/* ... rev=1.9999 could not be opened. Maybe the Serendipity or SourceForge.net Server is down - we are sorry, you need to try again later.Trying to open URL http://cvs.sourceforge.net/viewcvs.py/* ... additional......
Trying to open URL http://cvs.sourceforge.net/viewcvs.py/* ... additional......
Trying to open URL http://cvs.sourceforge.net/viewcvs.py/* ... additional......
Error: serendipity_plugin_amazon:fc18f057c0d5e47b4bdbf5bbb5e5cb02 (serendipity_plugin_amazon)

Fatal error: Call to a member function introspect() on a non-object in /home/pod/chiaraqu/serendipity/include/admin/plugins.inc.php on line 664

This would simply not happen with a PEAR-based installation, because the code has a HUGE userbase. It's about distributing development. s9y would simply be about being a great blog rather than wearing two hats.

3) downgrading a broken plugin, installing plugin dependencies - all of this becomes a piece of cake

Plugins currently have to bundle anything they use. This could lead to a lot of redundancy and wasted duplication. Dependencies can also be installed by the PEAR installer and managed easily.

Hope this helps explain the logic behind the choice :)

Greg
Post Reply