User:Talmdal

Gx Thoughts

Context

Just to provide some background. I don't consider myself a Gallery2 power user. I don't have an embedded gallery. My Gallery is pretty basic (http://www.timalmdal.com). Beyond the basic "display album and images", I use the following modules: hidden, notifications, comments, digibug, url rewriting, image block, albumselect, registration, cart, slideshow, dynamic album, and contact owner.

As a basis for what i want to see in the new version, I thought I'd take a moment to summarize what I believe are its strengths and weakness, so we can make an effort to not "throw the baby out with the bath water."

The Good

• It works... it displays images and lets you group them into "logical" albums
• It was originally well designed and modular
• Full feature set
• It is easy to add new features via modules or themes (if you are not the one writing them)
• Downloadable Plugins: allowing module and theme updates without a downloading the entire application
• Guided installs and upgrades
• Not seen by most users, but high unit test coverage

The Bad

• The API is complex and it is difficult to write new modules well.
• When displaying a page, the whole page is refreshed
• Difficult dynamic themes.
• You are unable to upgrade core using downloadable plugins.
• Multiple install packages
• Confusing upload options
• WebDav and Http Auth (Good idea... just complex and difficult to maintain)
• Events and Notifications are basically duplicate systems

The Ugly

• The application and framework are tightly integrated.
• There has been a tendency to include to much (i.e. themes and modules) into the main product
• Full page refresh.

Feature Wish List

Being a non power user, i don't have a large requirement for specific features, but more of an overall approach to implementing them. So here is my minimal wish list:

• single click install
• minimal install package. We should only deliver the minimum feature set as an install package. Then allow extensions and updates to be downloaded as required.
• No automatic detection of updates. Currently, if a module code is updated, the user (even if not the admin) is immediately taken to the upgrade screens. In Gx, the user should not know that a upgrades are available.
• Downloadable plugins should appear as a single repository
• Language translation should be an extension module.

• Required features:
  • Simple upload based on jhilden's work
  • Display album and images
    • jpeg, bmp, png, tif
  • Comparative to the current minimal installation
• In other words not much. I would much rather see us focus on a really slick interface for a limited functionality. And spread more of the extension modules outside of the core team to help provide maintenance.

Technology Thoughts

Tiered Feature Set

I would like to see a tiered feature set that would require increased coding standards and testing standards as a feature moves up the tiers. At the highest tier, would be the application framework, the next level would be features that make up the basic install package. The 3rd tier would be modules that are supported by the core team, but are not part of the base install. The next n-tiers would be team/user maintained modules. Which tier a module was in would depend on the quality of code, adherence to coding standards, unit test coverage.

Design Considerations

• Design with embedding as a priority.
• Design the Gallery2 application as a small lightwieght embedding application which, uses the same embedding API to provide a light weight gallery for those that don't need or want to embed in a blog or content management system.
• Pick your paradigm, SOA, RESTful, etc. but build the new infrastructure in a service oriented approach.

Template or Not to Template

I would prefer not to use a templating product. In looking at some of the frameworks, they are able to do quite a bit with views based on php scripts. I'm not sure what using something like Smarty is buying us for the complexity it is adding to developing views.

Framework Thoughts

• No frameworks that are still supporting PHP 4.x.x unless they have a specific PHP 5.x version.
• Provide standard validation as part of the model before going to the database.
• Needs to provide ACL and Auhtorization
• MVC - views have no data base calls or data manipulation... basically take the data by the provided by the controller and render it.
• Nested views (http://docs.kohanaphp.com/general/views#views_within_views)
• Needs to allow for a user to extend it with out changing the base libraries.
• Minimize what goes into the web accessible directories. For example, in Kohana, the specification of where the application and the Kohana framework are located is done in in the index.php. So all that is in the web directory is the index.php file.
• Prefer to focus on frameworks that are framework projects (Zend, Code Igniter, Kohana, CakePhp) as opposed to ones that are frameworks for an application (i.e. Drupal). One concern is that if we used something like the Drupal framework is that we could lose our identity and just become the an extension module to Drupal. The other concern is that it becomes difficult to distill out the essence of how to the framework api works from the "how to add a module to your installation"
• Currently, I've looked CakePhp, CodeIgniter, Kohana and Zend. At this point, I'm leaning to Kohana or Zend as they are only PHP5.

Operating System Support

• Windows support
  • Lets not worry about that... if we choose the proper framework, then it should handle a lot of that for us.
  • I agree with the comment made somewhere about the relationship we are starting to establish with Microsoft.

Database Support

• It would be nice if we could come up with a embedded database.
• Stored Procedure Support would be useful
• I think one database product is fine.