1. AppDB current status and proposed extensions
Marios Chatziangelou, IASA

2. Current status Sprint Task Duration Weeks Persons Architecture S1
Migrate DBMS to PostgreSQL - DONE 4 1 S2
Audit and re-factor existing codebase – DONE
Information Retrieval S3
Re-implement searching/filtering mechanism - DONE 3 S4
Applications entry tagging mechanism - DONE 2
Quality of Information S5
User comment/ranking system - DONE S6
Entry problem reporting system - DONE
1.5 S7
Broken link detection notification system - DONE S8
Application revocation mechanism (only for Managers) - DONE S9
Detect and promote or remove non-finished apps based on status – a list will be sent to UCST next week
S10
Development of mechanism to ensure future application/tool name uniqueness – DONE (UE)
Dissemination
S11
Notification services ( /RSS) – will be available for evaluation on 14/11/2011
Cross-browser Compatibility
S12
Investigation and estimation of Internet Explorer 9 (IE9) compatibility – Partially done, will continue

3. Moved to the next work-cycle
EGI User Support Platform
S13
Develop new/extend existing gadget with write access to the AppDB 4 1
S14
Provide write-access through API

4. Ideas for extensions (1)
E1. Restructuring the AppDB users interface
Provide multiple views and categorizations for the existed Applications & Tools :
New categories and views for dynamic content:
most visited,
top rated,
most popular(?),
most new apps,
most recent updated apps, etc,
Extend the main categorization, into:
applications,
portals,
suites,
frameworks,
operational tools,
generic tools,
appliances (!!!), etc.
(specific definitions for each one are needed)
More categories and views based on:
discipline,
sub-discipline,
middleware,
regional,
VOs etc.

5. Ideas for extensions (2)
E2. Additional metadata
In order to expand our target group and to attract more scientists and/or communities into the AppDB, we should need to extend the information/metadata that is held in the db
Examples of such metadata:
development framework and compilers that were used for the application
compatible OS(s),
libraries,
instructions on how one can use the application on the Grid,
application porting how to guide(s),
minimum resources needed,
benchmarking results (if any) on a grid environment,
etc.

6. Ideas for extensions (3)
E3. Increase visibility of the newly registered people
developing a separate embedded widget and showing the newly registered
members (with pictures) on the main page.
E4. Integrate the AppDB with external social networks
i.e. Facebook, Twitter, Google+, Fickr, Linkdn
E5. Content translation facility
using external 3rd-party translation services, such us Google translator

7. Ideas for extensions (3)
E6. Upgrade AppDB searching facility
list search results in a ranked descending order (like google does)
E7. Extend the AppDB gadget
In order to adapt all the new features developed for the AppDB portal in the current work-cycle.
Problem/error reporting
Tags
Rating facility
Comments etc.

8. Ideas for extensions (4)
E8. Investigation on EGI CRM – AppDB integration
Investigate the integrational capabilities offered by the chosen CRM system.
E9. NIL-ifize the NGI coordinators
Replace the NGI coordinators with the profiles of the NGI International Liaisons as the country contact points for the registered applications

9. Ideas for extensions (5)
E10 & 11. Satisfy the two sprints moved from the previous work-cycle:
- Develop new/extend existing gadget with write access to the AppDB
- Provide write-access through API

10. Ideas for extensions (5)
E12. Extend the AppDB with a source code repository
Increases the visibility of the AppDB (bigger audience –daily interaction)
Associate AppDB metadata with actual source code.
Satisfy application porting needs
Populate software releases through the AppDB channels (UI, Gadget, RSS, notifications etc)
Central, reliable, and well-formed (structured) code repository for further usage of the applications into the EGI infrastructure (VO or site-wide installations)