joeey1984ad / buddypress-media

Automatically exported from code.google.com/p/buddypress-media
0 stars 0 forks source link

AJAX API #7

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
[Describe this work unit]

Create a full-scale AJAX API for BuddyPress Media that allows Javascript and 
Flash based agents to pass data to and from the plugin core. 

This is *not* a REST-ful API like developers use to connect to Facebook, 
Flickr, and Twitter. This is a session-based API that allows authenticated 
users to interact with the system. It will probably require a very different 
design pattern.

===

Overall Goals:

-Create an API with enough functionality that template developers can emulate 
and surpass the user interfaces seen on FaceBook and Flickr. 

-Structure the API in a way that allows it to be easily extended by other 
developers. As the project gains traction, other developers will be able to 
help us improve it.

-The API should provide useful error messages to help new developers. If a call 
fails, it should return an error string that explains *why* the call failed. An 
option should be provided for writing errors to the system log (many developers 
do not know how to look at returned data from AJAX calls using Firebug)

-Get it finished as quickly as possible ..it does not have to be a "perfect" 
API, it has to be a "useful" API.

Research:

-Find some major sites / plugins that implement this kind of interface, and see 
what design techniques we can learn from them.

-Study the built-in WordPress AJAX functions, and how BuddyPress already uses 
them. Based on what I have seen so far, this is some *very* nice code in there.

-HTML5 ...are there any things we need to keep in mind / can take advantage of 
/ as the browser world starts to migrate to HTML5. This is especially important 
with video content. Wikipedia would probably be a good starting point.

Methods:

-Creating a complete list of methods is part of the work unit.

-Methods should be "idiot resistant" with "safety override". If something not 
dangerous (drop item) is posted to the API, it should allow the request. If 
something dangerous (drop entire album) is posted to the API, it should reject 
the request unless a "safety flag" has been set. The last thing we want is a 
badly designed template destroying a user's uploaded content. 

-Item creation. File upload. Ability to set DB fields for an item.

-Every way possible to query the database. Ability to return item counts, all 
stored fields, URL's to all sizes of an item and their cache status.

-Anything else the template developers suggest. We can't even begin to guess 
what people need for the sites they're developing ...we should let them tell us.

Implementation:

-The AJAX API will be implemented as its own separate component/class to allow 
it to be isolated from the rest of the plugin and re-used / learned from by 
other developers.

[What components of the plugin will be affected by this change]
Uploads, Admin Menu. 

[Does this work unit block any other work units?]

"Post Items Directly To Activity Stream" and "Group Albums" require this 
component to be completed before they can be built.

[Estimated hours of developer time this work unit will require]

30-40 hours.

[Estimated completion date]

2010-08-01

Original issue reported on code.google.com by CarlRoett@gmail.com on 15 Jul 2010 at 9:30

GoogleCodeExporter commented 9 years ago

Original comment by CarlRoett@gmail.com on 17 Sep 2010 at 9:38

GoogleCodeExporter commented 9 years ago

Original comment by CarlRoett@gmail.com on 17 Sep 2010 at 9:54