__MAGIC_REMOVE__10916__
Chris Kelly
Me: http://ckdake.com/
My Photos: http://ckdake.com/gallery/
Gallery Work: http://ckdake.com/projects/gallery/
- Gallery Project Manager
- G1 Release Packager
- Developer/Coordinator of XML-RPC for Gallery2.
TODO
news announcements to go out
- separate in depth page for each thing on the old http://galleryproject.org/whats_cooking_in_gallery_2_2
- h0bbel: summary of Gallery related news on the web (technorati, etc)
- fryfrog: summary of things going on in dev land (status reports, future releases, etc)
- call for documentation writers
- Tools to talk to Gallery 2 : GLoSS 1.0.0
- G2 trivia: # of translations, integrations, modules, etc
project manager sorts of things
- I currently monitor what I think is all the mailing list that are related. I scan though all the emails, respond to Gallery related ones on non-Gallery lists as appropriate, and jump in on the Gallery related ones as appropriate. The current list is: all the sf.net trackers, forums, g@mc, all of the sf.net mailing lists, redhat and gentoo security announcements, secunia and bugtraq mailing lists,
- responsibilities
- Managing fringe team members (eg Mike)
- Dealing with all of our affiliate relationships
- Individual communication with all team members
- Dealing with gallery@menalto.com mail
- Being point of presence for project
- Managing relationships with other projects
- Setting the tone/attitude for the project
- Minimizing conflict
- Monitoring GMC versioncheck pages
- locking commenting on GMC for page 2 items when new news goes up to prevent spam
- figure out why drupal sends emails for users accounts created with // in the url where the user id should be. users hitting back at just the wrong time?
- Gallery 1.x roadmap with Jens
- tech writer recruiting
- we need a number of these
- announcement
- pay/rewards/competitions?
- specific areas where docs could be useful Codex:Documentation_Requests
- do we need organization of the documentation categories completed first?
- ISP qualification program -> Certified_Web_Hosts
- contact http://frommel.net/gallery/ and ask him if he'd like to share/gpl/give-us his theme (it's G1, noted bharat if he noticed..)
sf.net trackers
- design new categorization for RFEs for G2
- remove [G2] marker
- Groups for G1, G2, GR
- Categories:
- core/framework changes
- new modules
- module extensions/changes
- new themes
- theme changes
on the codex
bugs
G2 Code
XML-RPC server module
- code in http://cvs.sourceforge.net/viewcvs.py/gallery-contrib/remoteprotocol/
- finish handoff to User:Bharat
- Unit Test problems
- Notice: Undefined offset: 1 in /home/ckdake/public_html/gallery2/modules/remoteprotocol/test/phpunit/RemoteprotocolXmlRpcTest.class on line 56
- remoteprotocolxmlrpctest
- see what happened to passing in an array of ids and getting back an array of results for every function where its reasonable (compare current core methods to stuff in http://cvs.sourceforge.net/viewcvs.py/gallery-contrib/xmlrpc/)
- start designing "link to other gallery" using xmlrpc
- "gallery of galleries" for gmc
- start off with just an xml-rpc client for GalleryItem
- do that now?
- look at the webcam module for starting ideas
GX
my thoughts. in progress.
Features
- Gallery owner can add jpgs to their Gallery using a very simple form in their browser
- Gallery owner can import an entire G1/G2 or just selected albums from a G1/G2.
- Gallery owner can add jpgs to their Gallery from their iPhone (email in, app to upload using api, app to upload to filesystem somehow, i dun care)
- Gallery owner can choose to organize items by event on a timeline (in one use case: albums for each year and subalbums for each event, orders by event timestamp), or by albums, both of which will use thumbnails to present an overview.
- Gallery owner can choose which item's thumbnail will be used to represent the event/album
- Gallery owner can edit tags, geotags, and timestamp information associated with individual items or entire albums.
- Gallery owner can edit simple theme files to control what information is displayed with images (map, tags, EXIF, etc)
- Images are displayed in the proper orientation (EXIF rotation field is cleared if rotated image is stored to disk)
- Visitors can search for particular images using tags and basic boolean logic
- Visitors can see where an image was taken on a map and see what pictures were taken at the same place and/or nearby. (ala flickr's organize map)
- Visitors can see EXIF information (including Canon lens information) associated with an image
- Gallery owner can use an API to do everything that they might otherwise do in the web interface (including getting image content and uploading images)
- Visitors can use an API to do everything that they might otherwise do in the web interface (including getting image content)
- Gallery owner can "star" photos and albums and set the default behavior to show all or only starred
- Visitors can filter to view only "starred" photos/albums or all photos/albums
- Random Images and Recently Added albums can be pulled into image blocks for use in other places
- Visitors can subscribe to an RSS feed of new albums/events which includes thumbnails of the album/event.
Functionality
- Changes to image metadata should be written to files.
- Images shouldn't have to have names. I don't know the best way to make URLs out of something without a name, but event name, tags, and timestamp are all I'm interested in
- Visually embeddable in Drupal - I don't care about users/etc, just as long as the URLs look "right" and my Drupal theme works
- Watermarking - I want GX to watermark images for me and preferably block hotlinkers with a different image or watermark
- Image firewall - I don't want people to be able to save my non-watermarked images, and I think this is a good way to plan ahead to allow for something like Amazon S3 based storage
- No caching on the filesystem - support for a user-cache in something like APC/etc makes a lot more sense
- The more I think about it, the database really should just be a cache: the few things that are outside of the folder structure of the images or embedded image metadata could easily be stored in a special file in gXdata. This way, any version of GX can use a folder tree, other apps can make changes that are reflected in the web ui, images can be added directly to the filesystem and moved around, etc. So perhaps just using APC/memcache/etc to do the "work" here is ok?
Things I don't want
- Permissions
- Custom arbitrary ordering of things (by timestamp ascending/descending is fine)
- Asynchronous jobs - people can run it in a site admin window and wait, or things like thumbnails can be generated ondemand the first time
- Comments - just no interest in these
- User accounts other than mine (I guess other people will want these, but why not have each person with their own entire GX?)
- Permalinks
- Any kind of media other than jpgs (Gallery is "photos")
- A multi-step installer. One page is plenty, if a page is even needed.
Related Links
hello kitty digital camera
