Wombat/Tasks

Next Actions

The milestone for these goals is 0.3.0

Apache Hosting (2.3 DEP, 2.5 DEP)

DONE

Qualified Domain Hosting (within worldforge class)

DONE

Automated Meta-Data Updating

1. Watch for updates (via Repository Hooks for SVN, CVSROOT/loginfo, Git? )
2. Update only the portions of the repository that are dirty.

Cosmetics

1. Home Page should display directory root. No reason to require to clicks to start browsing. DONE (Also added a link for Status and made Directories a link in the menu so you could get back from the status page)
2. Presently it feels like you can drill down for a good while before you hit any media. We should give some sort of indication or visual preference to folders that contain a lot of media/folder ratio.
3. I'm debating whether or not this is a good idea, but it seems like in the menu folder list we could supply the "next tier down" of folders for browse-to. Either that or let the entire tree be browsable by drill-down over there and load subordinate tiers in via ajax. I'd like to have some discussion about this before we do anything, performance of loading a page for each folder has the potential to be abysmal. (You could potentially just load the directory names themselves into the tree and have something like walk the tree to the directory you want and then hit the go/navigate button to bring up the normal directory view. It wouldn't have the performance hit and should still be a lot faster to browse through).
4. When expanding a file node, switch the 22px icon to a spinner to show that something is happening.
5. Thumbnails for assets should appear to the left of the details table. (If we do this the details tab will be one size for images and another size for sounds/text). Does that make it look funky (technical term) or is it ok?
6. Display of text files should be placed at the bottom of the details table in a scrolling div. DONE
7. SVG can indeed to included as output. (for most browsers anyhow.)
8. Move file size in list view to beneath the name, left aligned with the name.

Discuss 2.2 for plausibility and usefulness.

This will take some more time to implement correctly, but a preliminary version is done already.

Allow users to bookmark certain files/directories

(store the paths in a cookie) and display them on the left with navigation and allow the storage of searches as well. (Think OSX "Smart Folders" apple.com)

Sorting of files based on user-preference (cookie-based.)

Using Javascript where possible to avoid controller-layer clutter. (from rflahert: Sorting of displayed results both for searches and normal navigation (maybe provide option for sort by size, alphabetically))

(Ledged or postponed items from previous 0.2 planning)

Application Status Screen

• Number of unique visitors today.
• Number of commits today.
• Number of commits this week.
• Most popular path in repository. At first I was thinking that this would be easy to do by counting updates/commits in each branch of the repository however I realize now the error of my concept. Instead we'll want to see which items are being viewed most frequently and list the top 5 or so. This might rely more on a separate data storage device for tracking user behavior to prevent gaming.
• RSS feed for updates. Will require commit log tracking. I think there's a plugin for SVN that produces RSS feeds that maybe we could use and just pass-thru. (via Repository Hooks for SVN, CVSROOT/loginfo, Git? )

Fix issue with interlaced PNG files (Search for flat.png and try bringing it up).

DONE

Rewrite the data model to mirror the new design plan.

See the in progress document for WOMBAT as well.

Near-Term Action Items

Thumbnail and Document Preview Rendering

Files which are utilized by common WF clients must have thumbnails generated for them. This should include at a minimum:

• mesh Files used in Ember
• wrml VRML type files
• fbx 3d Files
• cal3d Files
• collada Files

Files such as text files, script files and source code files should be rendered with some form of baseline syntax hi-lighting.

Changing Browse Mechanism to Display All Files

An alternative interface concept which puts in the #content section of the application a list of all files visible recursively from the current selection in the directory hierarchy. By drilling down into the structure further, the user limits the number of files visible in the content section. Coupled with a method for quickly filtering by type, string filter, date range, etc. this methodology puts the assets front-most in the application.

HTTP Authentication (WF User accounts standard.)

A form within the document should relay to a standard component which utilizes http authentication to validate a user's identity. (Better than using the browser dialog, gives us a chance to partake in the handling of the data.) Authenticated users with permission to edit /data/users locally should have the capability of adding new user accounts through the application which produce the appropriate user accounts locally. (AuthKit?) Three groups of users should be sufficient (Team Leads/Artists/Visitors)

User-Preference Storage

Authenticated users should have a serialized data source for storing preferences within the application. This file should be stored in a sub-directory of their user directory within the DAV share.

File Sharing Integration

Users should have access to a self-titled DAV share to which they can push changes for staging into the repository. Users should have access to a self-titled DAV share from which they can pull files from the repository based on VCI activity.

Version Control Integration

Users should be able to stage a file into their self-titled DAV share for modification. (locking at checkout?) Users should be able to import any files into the repository from their self-titled DAV share where the modification date of the file in the share doesn't match the modification date in the repository. Users should be able to prepare and submit a commit log for any single session worth of activity. At the time of submission of this document, any pending changes should be committed as well. Commit-tracking for the status screen should be implemented. See 1KM.7.

Review Moderation Subsystem

Building on the VCI, files and trees within the repository can be flagged for moderation. Any moderated tree within the repository will have all pending commits await approval by the moderator. Un-moderated commits should wither over time; else have the moderation flag decay such that stagnation does not occur due to non-management. Messaging will be required to support this system such that a team lead can communicate with artists about specific works, groups of works (or directories of works.)

Type-Ahead Searching of Repository

When searching by string for files in the repository the interface should display a list of the most recent matching files by name. (See store.apple.com search for example.)

1. Prepare a new mako for producing a UL set of file results. (minsearch.mako)
2. During scan lay aside the most recent 100 results from each type of file in the repository. (/data/minsearch.index)
3. Produce a method to return minsearch.mako from a querystring entered by the user. Return the top 3-5 results that match from each unique file type set. URL:: <http://wombat/minsearchpanel/?query=string> (Submission of the search form will redirect the user to the standard search results page.
4. Produce javascript method and state variable controller for displaying disclosed panel containing search results asynchronously. AJAX calls should fire on timeout delays of one second discarding any timers in play during execution.

Long Term Goals

Application Bundle for Redistribution

All supporting libraries, build configurations for 3rd party applications and configuration files should be highly documented for use outside of the single WF distribution of Wombat.

Per-Application Services Integration

An abstract RPC interface should be devised which allows for integration from applications such as: Gimp, Blender, Photoshop for integration with our Media Management System.

Separate out version control access into modules

to access svn you would use the svn module, cvs would use the cvs module, etc. With a documented module framework we could develop our own VCS modules or others could develop ones for their favorite flavor.