Hey guys, I'm talking especially to the web app developers here, but I also hope that other people will chime in with useful thoughts.
As part of python-fedora, I've started documenting some standards for Fedora Services. These will go hand in hand with documents on how to use BaseClient that I am in the process of writing. These documents will document how Fedora Services should be written rather than how they are currently implemented. As such, I want to make sure everyone:
1) has a chance to review the document and make comments/changes before the changesare integrated into BaseClient and people have to port to things that are backwards incompatible.
2) can bring up other areas that need to be addressed.
For instance, skvidal recently wrote a short client to the pkgdb that can generate email aliases for packages (so package@packages.fp.o could send mail to all the committers to a package). He had the following comments to make:
1) It would be nice to have an introspection API to look at what methods are available on a TG app and how to use them.
2) JSON data that is deeply nested sucks because objects are turned into dictionaries so you have to write things like:
package['listings']['F-8']['people']['toshio']['acls']['commit']['status']
to get the status of a person's acls on a package.
I'd like to get other people's input on how to work on these and any other issues before completing the next python-fedora so I can be sure that I've got most of the incompatibilities in. Talking here and on IRC is welcome.
Here's the current version of the Fedora Services Documentation. What's there should be complete. Addressing skvidal's concerns hasn't even been stubbed out yet:: http://tinyurl.com/52xmjw
The BaseClient Documentation is still in heavy flux. It's here:: http://tinyurl.com/4ww6v7
-Toshio
On Sat, Apr 26, 2008 at 10:38:51AM -0700, Toshio Kuratomi wrote: [snip]
- JSON data that is deeply nested sucks because objects are turned into
dictionaries so you have to write things like:
package['listings']['F-8']['people']['toshio']['acls']['commit']['status']
to get the status of a person's acls on a package.
When writing zmugfs I used simplejson.loads(rsp, object_hook=create_tree) where create_tree is an object creation method. The other option is to change the depth of the object returned.
Jesus M. Rodriguez wrote:
On Sat, Apr 26, 2008 at 10:38:51AM -0700, Toshio Kuratomi wrote: [snip]
- JSON data that is deeply nested sucks because objects are turned into
dictionaries so you have to write things like:
package['listings']['F-8']['people']['toshio']['acls']['commit']['status']
to get the status of a person's acls on a package.
When writing zmugfs I used simplejson.loads(rsp, object_hook=create_tree) where create_tree is an object creation method. The other option is to change the depth of the object returned.
This sounds interesting. How do you tell which dictionaries can be turned into objects and which must remain dictionaries? Or does your create_tree method have special knowledge of the data being returned?
-Toshio
On Sun, Apr 27, 2008 at 01:12:09PM -0700, Toshio Kuratomi wrote:
Jesus M. Rodriguez wrote:
On Sat, Apr 26, 2008 at 10:38:51AM -0700, Toshio Kuratomi wrote: [snip]
- JSON data that is deeply nested sucks because objects are turned into
dictionaries so you have to write things like:
package['listings']['F-8']['people']['toshio']['acls']['commit']['status']
to get the status of a person's acls on a package.
When writing zmugfs I used simplejson.loads(rsp, object_hook=create_tree) where create_tree is an object creation method. The other option is to change the depth of the object returned.
This sounds interesting. How do you tell which dictionaries can be turned into objects and which must remain dictionaries? Or does your create_tree method have special knowledge of the data being returned?
The create_tree in this example knows that it is building a Tree. I also have a create_album which creates an Album. It isn't generic at all, but it does offer a way to return objects from json responses quite easily.
On Sat, 2008-04-26 at 10:38 -0700, Toshio Kuratomi wrote:
Hey guys, I'm talking especially to the web app developers here, but I also hope that other people will chime in with useful thoughts.
As part of python-fedora, I've started documenting some standards for Fedora Services. These will go hand in hand with documents on how to use BaseClient that I am in the process of writing. These documents will document how Fedora Services should be written rather than how they are currently implemented. As such, I want to make sure everyone:
- has a chance to review the document and make comments/changes before
the changesare integrated into BaseClient and people have to port to things that are backwards incompatible.
- can bring up other areas that need to be addressed.
For instance, skvidal recently wrote a short client to the pkgdb that can generate email aliases for packages (so package@packages.fp.o could send mail to all the committers to a package). He had the following comments to make:
- It would be nice to have an introspection API to look at what methods
are available on a TG app and how to use them.
- JSON data that is deeply nested sucks because objects are turned into
dictionaries so you have to write things like:
package['listings']['F-8']['people']['toshio']['acls']['commit']['status']
to get the status of a person's acls on a package.
I'd like to get other people's input on how to work on these and any other issues before completing the next python-fedora so I can be sure that I've got most of the incompatibilities in. Talking here and on IRC is welcome.
Here's the current version of the Fedora Services Documentation. What's there should be complete. Addressing skvidal's concerns hasn't even been stubbed out yet:: http://tinyurl.com/52xmjw
The BaseClient Documentation is still in heavy flux. It's here:: http://tinyurl.com/4ww6v7
Nice, I need to fix up my stuff to use the BaseClient stuff. Right now I do it manually. We need to do the same type of documentation for writing widgets and come up with some standards for using JavaScript (such as use JQuery) for AJAXy stuff. I'll go over your docs in more detail on Monday and comment. What I would really like to see is this not just be a doc but be an example site much like the API documentation on the JQuery site. For instance for BaseClient, have working examples for each of the important API pieces which demonstrates how to use them and what to expect as output.
infrastructure@lists.fedoraproject.org