GeeklogWiki - User contributions [en]

SoC full openid support

2009-06-03T21:36:37Z

Choplair: + present GSoC develpment information / links

This is one of the projects to be implemented during the [[Google Summer of Code]] 2009.

'''Student:''' Choplair, '''Mentor:''' Randy Kolenko

== Project info and advancement during Summer of Code ==

Thomas Gutleben, aka ''Choplair'', has been selected to achieve this project.

The independant OpenID library that needed to be created for the occasion has been named '''GGGOOOIIIPPP''', for "''Geeklog GNU GPL Object Oriented Opend ID Implementation In Pure PHP Project''".

Dedicated SourceForge account and website have been set up to obtain docs / information, grab source code and follow development in real-time.
* SourceCode project summary: http://sourceforge.net/projects/gggoooiiippp/
* Dedicated website: http://gggoooiiippp.sf.net/

== Pre-Summer of Code idea discussion & preparation ==

=== Incentive ===

Geeklog has had support for OpenID since [http://www.geeklog.net/article.php/geeklog-1.5.0 version 1.5.0].

However, it currently only supports OpenID 1.1, you can only allow users to login using OpenID but can not have your Geeklog site act as an OpenID provider, and the library we are using isn't supported any more.

So for this project, we are looking for

* OpenID 2.0 support
* support for both the Consumer and the Provider side

=== Details ===

The idea behind [http://openid.net/ OpenID] is to provide a generic login that you can use to log into any site that supports OpenID without the need to register with all those sites. The current version of the OpenID specification is 2.0 and has since been widely adopted and received backing from many well-known names.

==== Consumer and Provider ====

OpenID covers both sides of the login process: A website can allow users to login using their OpenID (i.e. act as a ''Consumer'') and it can provide an OpenID identity for users (i.e. act as a ''Provider'') which they can then use to log into other OpenID-enabled sites.

A Geeklog site can currently only act as an OpenID consumer. We would like to see this extended to allow a site to also act as an OpenID provider for their users.

Things to consider:

* It should be possible to limit providing an OpenID identity only to members of a certain Geeklog group.
* An OpenID login consists of a URL. We would need a simple and memorable URL scheme on the Geeklog side that can be used as the OpenID login.

==== Finding an OpenID Library ====

The main problem with this project is to find a usable OpenID 2.0 library. When checking the [http://wiki.openid.net/Libraries list of available libraries] it turns out that all the PHP libraries listed there suffer from one or more of the following problems:

* does not support OpenID 2.0
* does only support one side (Consumer or Provider, but not both)
* is part of an exisiting framework
* is not available under a license that's compatible with the GPLv2

So the student's first task would be to research the available options and see if there is an OpenID library that fits our requirements or if it has to be implemented during this project.

==== New Implementation? ====

Should it turn out that there are no suitable libraries available, we would like to see a new library being implemented that is

* object oriented
* reusable (and, specifically, ''not'' tied to Geeklog)
* supports OpenID 2.0
* allows for both the Consumer and the Provider side
* published under the GPLv2 or a compatible license

Developing a new library would take up a good portion of the available time for this project, so it's possible that the student won't be able to finish integration of the library into Geeklog. We're willing to accept this in exchange for a solid and usable OpenID library.

Also see [http://eight.pairlist.net/pipermail/geeklog-devel/2009-March/004139.html this post] on the geeklog-devel mailing list for some clarification.

=== Level of Difficulty ===

The level of difficulty depends on the availability of a usable OpenID library:

* ''hard'' - if the OpenID 2.0 library has to be implemented by the student.
* '' medium'' - if a suitable library exists.

[[Category:Summer of Code]] [[Category:Development]]

SoC plugin repository

2009-05-09T17:25:18Z

Choplair:

<center>(This is an idea page for the [[Google Summer of Code]])</center>

== Project info and advancement during Summer of Code ==

(to be written)

== Pre-Summer of Code idea discussion & preparation ==

=== Incentive ===

Geeklog's functionality can be extended by plugins, i.e. add-ons that use the dedicated plugin API which allows them to be seamlessly integrated into Geeklog. The standard Geeklog distribution ships with some plugins pre-installed (Calendar, Spam filter, etc.). Other popular plugins include a forum and image galleries.

Traditionally, installation of a plugin was a somewhat awkward process: After unpacking the tarball or Zip archive, you have to rename and move three directories into specific places, then run the plugin installation script.

Thanks to the Google Summer of Code, this is about to change in Geeklog 1.6.0. Now you can upload plugins directly from Geeklog's plugin admin panel. Geeklog will take care of moving the directories into their proper place and also run the install automatically.

With this project, we want to take things one step further and allow plugin installation over the internet.

The idea is to provide a plugin repository from which the admin of a site can easily pick a plugin for installation.

=== Details ===

To allow installation of a plugin from a plugin repository, both sides have to be implemented. So the goals of this project are

* Implement a "Plugin Repository" plugin
* Extend the plugin admin panel in Geeklog to allow download from a plugin repository

==== Plugin Repository ====

The plugin repository should be implemented as a Geeklog plugin itself. It will be installed on sites that want to provide plugins for download. Geeklog's homepage would be an obvious use case, but plugin authors may also want to provide their own repositories on their own sites.

The general features are similar to those of the existing File Management plugin, namely

* allow users to upload plugins
* require approval from a moderator
* allow users to download the approved plugin

The repository should allow more flexibility here, though, depending on the use case, e.g.:

# an "Open" setup (e.g. geeklog.net):
#* any user can upload
#* users can update their submission (requires re-approval)
# a "Closed" setup (e.g. plugin author's private site):
#* only dedicated users can upload
#* no approval required
#* dedicated users can update their submissions without approval

These options should be configurable.

===== Notes =====

* For large repositories, a category system would help to keep things maintainable and usable.
* Uploaded files should be checked automatically. For example, a minimal Geeklog plugin will always contain a file called <tt>functions.inc</tt> and should also include a file <tt>autoinstall.php</tt> to allow automatic installation.
* The repository should allow "traditional" downloads from a browser, too, in case users need to do manual plugin installs.
* Geeklog provides PHP classes for upload and download of files. The download from within Geeklog can be done using the PEAR HTTP::Request package.

==== Feeds ====

Information about the plugins in a plugin repository should be provided as feeds (e.g. Atom or RSS). A Geeklog site admin should be able to subscribe to these feeds easily in order to stay informed about new plugins and updates to existing plugins - especially updates of plugins they have already installed.

Geeklog provides a framework for reading and writing feeds in various formats (Atom, RSS, RDF).

==== Plugin admin panel ====

Geeklog's plugin admin panel should get a new pane that handles

* feeds and update information
* selecting a plugin for installation

==== Questions ====

Some questions and considerations to get the student started:

* Use case: User finds a new site that offers a plugin repository. How can they easily subscribe to that site's feed?
* A plugin that is installed from a repository could provide an update feed for itself. How should these be handled? This may require additional plugin API functions.
* Security considerations: Ensure integrity of plugin archives (checksums). What can we do about malicious plugin repositories?

==== Considerations for the Future ====

In the future (post-GSoC), we may want to extend the functionality to allow download and installation of other components, e.g. themes and language files. The code for this project should therefore be written in a way that it allows future extensions and avoids things like hard-coded paths or making assumptions that would only apply to Geeklog plugins.

=== Level of Difficulty ===

''medium''

Geeklog already provides solutions for the basic tasks: Uploads, downloads, plugin installation, feeds. Putting them all together in a way that's easy and secure to use is what this project is about.

'''Mentor:''' Matt West

[[Category:Summer of Code]] [[Category:Development]]

SoC webservices revisited

2009-05-09T17:24:17Z

Choplair: pre-SoC / present work content seperation

<center>(This is an idea page for the [[Google Summer of Code]])</center>

== Project info and advancement during Summer of Code ==

(to be written)

== Pre-Summer of Code idea discussion & preparation ==

=== Incentive ===

As part of the 2007 Summer of Code, a webservices API has been [[SoC_webservices_publishing|implemented]] in Geeklog. It provides the basic framework (RESTful communication, authentication) and implements the Atom Publishing Protocol (RFC 5023, ''Atompub'') for stories and the plugin API (with the Static Pages plugin as a sample implementation).

In this project, we would like the student to look into areas where the webservices could also be added and, possibly, where they need changes or additions.

=== Areas of Interest ===

The following areas would appear to make useful additions to the webservices API:

* image upload in stories
* story submissions
* comments

These would appear to make the most sense at this time, to round off the existing functionality of the webservices API and bring it in sync with what can be done through the normal web-based UI.

We are open for suggestions for additional areas where the webservices API could be used, though.

=== Details ===

==== Image Upload ====

When using the Admin's version of the story editor, a user can upload images that are to be used in the article (includes automatic thumbnail creation, link to the full-size version, etc.). This has been left out in the original implementation of the webservices API for the stories.

Atompub does have support for images and other types of media (''Media Resources''). Therefore, it should be possible to implement the image upload via the webservices API so that an Atompub client can be used to publish articles with images in them.

==== Story Submissions ====

A Geeklog site allows visitors to submit stories for publication on the site. These will usually have to be approved by a moderator first. Story submissions are stored in a separate submission queue until approved (or rejected). The webservices API should be extended to allow users to submit stories and moderators to approve or reject (delete) submissions.

Since moderation of submissions is also available for plugins (through Geeklog's plugin API), it would be preferable if this could be implemented in such a manner that webservices access is also available for plugins.

To be discussed: Whether to expose the existence of a submission queue or not. It may make sense to treat submissions as normal entries and only set the "draft" flag for them.

==== Comments ====

Comments by readers are supported for stories and plugins using the comment plugin API (e.g. Polls, Static Pages). There should be a way for users to submit (and possibly edit) their comments through the webservices API.

Note: Editable comments were part a [[SoC_improving_comments_2008|GSoC project in 2008]] and will be available as of Geeklog 1.6.0.

=== Level of Difficulty ===

''medium to high''

Implementing ''both'' the Image Upload and the Submission Queue is probably too big a project for the Summer of Code. Our estimate is that either of these would require about two thirds of the time of the program.

Students interested in this project should indicate which of the two sub-projects they would like to be working on.

=== Further Reading ===

* [[Webservices API]]
* [[Using the Webservices]]
* RFC 5023: The Atom Publishing Protocol

[[Category:Summer of Code]] [[Category:Development]]

SoC test framework

2009-05-09T17:23:30Z

Choplair: pre-SoC / present work content seperation

<center>(This is an idea page for the [[Google Summer of Code]])</center>

== Project info and advancement during Summer of Code ==

(to be written)

== Pre-Summer of Code idea discussion & preparation ==

=== Incentive ===

Very little testing on Geeklog is currently done automatically. As the complexity of the software is ever increasing, it's not enough to rely on manual tests done by the developers (and, by extension, the community during beta and release candidate phases) any more.

So the goal of this project is to implement test framework(s) to allow for automated tests of Geeklog and its features.

=== Details ===

There are two aspects that we'd like to see tested, which may actually make it possible to have this split into '''two''' projects:

* tests of the code on class / function level
* tests of the front-end functionality available through the browser

At the code level, [http://en.wikipedia.org/wiki/Unit_testing unit tests] are required to make sure the code behaves as expected at its interface (API) so that after making changes to the internals, the API still behaves the same.

Unit testing is usually associated with object oriented code, which may sound like a problem given that Geeklog is not fully object oriented. However, unit tests can also be written for the many collections of functions in <tt>system/lib-*.php</tt> and <tt>lib-common.php</tt>.

Testing the functionality implemented in, say, <tt>admin/story.php</tt> (the Admin panel that provides access to all stories on a site) is probably best done through a tool that tests the web frontend.

=== Frameworks ===

There already exist numerous test frameworks for PHP code and for web applications. So unless there's a ''very'' good reason not to pick one of those, we would suggest looking into existing frameworks (and adapt them, if necessary).

Here's an incomplete list of test frameworks. We expect the student to research more options before making a choice:

* [http://qa.php.net/write-test.php PHP Tests] (*.phpt) as used by the PHP project
* [http://www.phpunit.de/ PHPUnit]
* [http://seleniumhq.org/ Selenium]

Open source solutions would be preferred, although there are some commercial frameworks that may be worth looking into.

=== Level of Difficulty ===

''low to medium''

The focus in this project lies on picking the proper tool (i.e. test framework) and then demonstrating that it does the job by implementing tests for a representative portion of the code / functionality. We certainly don't expect complete coverage of all of Geeklog in just one summer. This project is about laying the groundwork.

[[Category:Summer of Code]] [[Category:Development]]

SoC full openid support

2009-05-09T17:21:37Z

Choplair:

<center>(This is an idea page for the [[Google Summer of Code]])</center>

== Project info and advancement during Summer of Code ==

(to be written)

== Pre-Summer of Code idea discussion & preparation ==

=== Incentive ===

Geeklog has had support for OpenID since [http://www.geeklog.net/article.php/geeklog-1.5.0 version 1.5.0].

However, it currently only supports OpenID 1.1, you can only allow users to login using OpenID but can not have your Geeklog site act as an OpenID provider, and the library we are using isn't supported any more.

So for this project, we are looking for

* OpenID 2.0 support
* support for both the Consumer and the Provider side

=== Details ===

The idea behind [http://openid.net/ OpenID] is to provide a generic login that you can use to log into any site that supports OpenID without the need to register with all those sites. The current version of the OpenID specification is 2.0 and has since been widely adopted and received backing from many well-known names.

==== Consumer and Provider ====

OpenID covers both sides of the login process: A website can allow users to login using their OpenID (i.e. act as a ''Consumer'') and it can provide an OpenID identity for users (i.e. act as a ''Provider'') which they can then use to log into other OpenID-enabled sites.

A Geeklog site can currently only act as an OpenID consumer. We would like to see this extended to allow a site to also act as an OpenID provider for their users.

Things to consider:

* It should be possible to limit providing an OpenID identity only to members of a certain Geeklog group.
* An OpenID login consists of a URL. We would need a simple and memorable URL scheme on the Geeklog side that can be used as the OpenID login.

==== Finding an OpenID Library ====

The main problem with this project is to find a usable OpenID 2.0 library. When checking the [http://wiki.openid.net/Libraries list of available libraries] it turns out that all the PHP libraries listed there suffer from one or more of the following problems:

* does not support OpenID 2.0
* does only support one side (Consumer or Provider, but not both)
* is part of an exisiting framework
* is not available under a license that's compatible with the GPLv2

So the student's first task would be to research the available options and see if there is an OpenID library that fits our requirements or if it has to be implemented during this project.

==== New Implementation? ====

Should it turn out that there are no suitable libraries available, we would like to see a new library being implemented that is

* object oriented
* reusable (and, specifically, ''not'' tied to Geeklog)
* supports OpenID 2.0
* allows for both the Consumer and the Provider side
* published under the GPLv2 or a compatible license

Developing a new library would take up a good portion of the available time for this project, so it's possible that the student won't be able to finish integration of the library into Geeklog. We're willing to accept this in exchange for a solid and usable OpenID library.

Also see [http://eight.pairlist.net/pipermail/geeklog-devel/2009-March/004139.html this post] on the geeklog-devel mailing list for some clarification.

=== Level of Difficulty ===

The level of difficulty depends on the availability of a usable OpenID library:

* ''hard'' - if the OpenID 2.0 library has to be implemented by the student.
* '' medium'' - if a suitable library exists.

[[Category:Summer of Code]] [[Category:Development]]

SoC postgres support

2009-05-09T14:59:25Z

Choplair:

<center>(This is an idea page for the [[Google Summer of Code]])</center>

== Project info and advancement during Summer of Code ==

(to be written)

== Pre-Summer of Code idea discussion & preparation ==

=== Incentive ===

Geeklog currently supports MySQL and MS SQL Server for the database. Recently, we have had an increasing amount of requests to add support for [http://www.postgresql.org/ PostgreSQL] (aka Postgres).

=== Details ===

Development of Geeklog started back in 2000 when most of today's database abstraction layers didn't even exist yet. It therefore uses its own (thin) abstraction layer and will have to continue to do so for the foreseeable future.

The idea is simple: Create a database abstraction layer for PostgreSQL for Geeklog. In theory, that would "only" require the implementation of one class in one file: <tt>system/databases/postgres.class.php</tt> (alongside <tt>mysql.class.php</tt> and <tt>mssql.class.php</tt>).

Due to Geeklog's thin database abstraction layer, some non-standard SQL has crept into the codebase here and there. The MS SQL implementation works around this by patching some of those requests at runtime. While our goal is to use standard-compliant SQL as much as possible it may not always be possible to change this for reasons of backward compatibility. Also, not all the code is under our control, e.g. in plugins.

In addition to the actual database class, there are also database-specific files to initialize and upgrade the database and the plugins. They usually include the SQL requests to be executed as well as, in case of upgrade files, some PHP code. Equivalents of these files for Postgres will also have to be implemented (obviously, we would not need upgrade files for older Geeklog versions).

=== Level of Difficulty ===

''medium to high''

Students interested in this project should be ''very'' familiar with Postgres to be able to work around the restrictions outlined above.

'''Mentor:''' Vinny Furia

=== Further Reading ===

* [http://www.postgresql.org/ PostgreSQL homepage]
* [http://www.geeklog.net/article.php/20060918173353100 Announcement] of the MS SQL support

[[Category:Summer of Code]] [[Category:Development]]

SoC postgres support

2009-05-09T14:58:31Z

Choplair: /* = Project info and advancement during Summer of Code */

<center>(This is an idea page for the [[Google Summer of Code]])</center>

=== Project info and advancement during Summer of Code ===

(to be written)

=== Pre-Summer of Code idea discussion & preparation ===

== Incentive ==

Geeklog currently supports MySQL and MS SQL Server for the database. Recently, we have had an increasing amount of requests to add support for [http://www.postgresql.org/ PostgreSQL] (aka Postgres).

== Details ==

Development of Geeklog started back in 2000 when most of today's database abstraction layers didn't even exist yet. It therefore uses its own (thin) abstraction layer and will have to continue to do so for the foreseeable future.

The idea is simple: Create a database abstraction layer for PostgreSQL for Geeklog. In theory, that would "only" require the implementation of one class in one file: <tt>system/databases/postgres.class.php</tt> (alongside <tt>mysql.class.php</tt> and <tt>mssql.class.php</tt>).

Due to Geeklog's thin database abstraction layer, some non-standard SQL has crept into the codebase here and there. The MS SQL implementation works around this by patching some of those requests at runtime. While our goal is to use standard-compliant SQL as much as possible it may not always be possible to change this for reasons of backward compatibility. Also, not all the code is under our control, e.g. in plugins.

In addition to the actual database class, there are also database-specific files to initialize and upgrade the database and the plugins. They usually include the SQL requests to be executed as well as, in case of upgrade files, some PHP code. Equivalents of these files for Postgres will also have to be implemented (obviously, we would not need upgrade files for older Geeklog versions).

== Level of Difficulty ==

''medium to high''

Students interested in this project should be ''very'' familiar with Postgres to be able to work around the restrictions outlined above.

'''Mentor:''' Vinny Furia

== Further Reading ==

* [http://www.postgresql.org/ PostgreSQL homepage]
* [http://www.geeklog.net/article.php/20060918173353100 Announcement] of the MS SQL support

[[Category:Summer of Code]] [[Category:Development]]

SoC postgres support

2009-05-09T14:58:15Z

Choplair: separation of content that prepared SoC, and (future) content about the concrete summer project advancement

<center>(This is an idea page for the [[Google Summer of Code]])</center>

=== Project info and advancement during Summer of Code ==

(to be written)

=== Pre-Summer of Code idea discussion & preparation ===

== Incentive ==

Geeklog currently supports MySQL and MS SQL Server for the database. Recently, we have had an increasing amount of requests to add support for [http://www.postgresql.org/ PostgreSQL] (aka Postgres).

== Details ==

Development of Geeklog started back in 2000 when most of today's database abstraction layers didn't even exist yet. It therefore uses its own (thin) abstraction layer and will have to continue to do so for the foreseeable future.

The idea is simple: Create a database abstraction layer for PostgreSQL for Geeklog. In theory, that would "only" require the implementation of one class in one file: <tt>system/databases/postgres.class.php</tt> (alongside <tt>mysql.class.php</tt> and <tt>mssql.class.php</tt>).

Due to Geeklog's thin database abstraction layer, some non-standard SQL has crept into the codebase here and there. The MS SQL implementation works around this by patching some of those requests at runtime. While our goal is to use standard-compliant SQL as much as possible it may not always be possible to change this for reasons of backward compatibility. Also, not all the code is under our control, e.g. in plugins.

In addition to the actual database class, there are also database-specific files to initialize and upgrade the database and the plugins. They usually include the SQL requests to be executed as well as, in case of upgrade files, some PHP code. Equivalents of these files for Postgres will also have to be implemented (obviously, we would not need upgrade files for older Geeklog versions).

== Level of Difficulty ==

''medium to high''

Students interested in this project should be ''very'' familiar with Postgres to be able to work around the restrictions outlined above.

'''Mentor:''' Vinny Furia

== Further Reading ==

* [http://www.postgresql.org/ PostgreSQL homepage]
* [http://www.geeklog.net/article.php/20060918173353100 Announcement] of the MS SQL support

[[Category:Summer of Code]] [[Category:Development]]