AGO3 ,like its predecessor(AGO2) , is going to allow variations of themes(or backgrounds). But I want to take a step further and have something more complex (and powerful).

In AGO2 every time a user submits a update of a theme, only one version is kept in the system. So no real history is kept. This is one of the things I want to change. Users will have at their disposal all the versions of a theme since it was released(if the owner doesn’t remove).

There will also be the possibility to create a branch of a previous theme. However, we haven’t decided yet how this will work. Will the new branch be defined as a new tree of versioning or stays connected to the current tree? Drom suggested to allow users to branch themes from other users, and if so, what about the licenses? Some may not allow those actions!
As you can see there are some decisions yet to be made.

Now, how am I thinking in implementing this?

In paper this can be drawn as a tree of nodes. Which quite different of the representation I have in an DB (flat tables). So I have to find a solution to store hierarchical data in a Database.

The bad way

The easier way would be to use an adjacency list model. With this approach I only need to keep the ‘parent’ of the current node. Whenever I need to find the ’sons’ of a node a single query to the DB is enough. The disadvantages of this solutions is in having to get all the nodes of the tree. For each node I need to do a query for its ’sons’. For each single ’son’ I’ll do a query for their ’sons’ and so on… This nice recursion is way to heavy in the DB! This definitely isn’t a solution. At least not a good one!

The Cool Way

I’ll be implementing an Modified Preorder Tree Transversal Nested Sets.
You can find more information on that subject in the nice article on Storing Hierarchical Data in a Database.
With this method, each node will have two values associated to it, left and right. The way those values are set gives certain properties that allows to only need one DB query to get all the tree nodes in the proper order.
This isn’t that easy to explain in few words, so if you are interested I recommend you to read the article I’ve mentioned

One of those properties is: If you have two nodes, A and B, and B’s left and right values are between A’s left and right values, it means that B is somehow descendent of A. Thus, if I want to retrieve all the descendants of a node I only need one query to get all the nodes where the left value is between my node left and right value (something like 'Select * from table_name where lft between 1 AND 11')

I’m introducing a variation in the method and keeping a field pointing to the ‘parent’ node. I will be needing to get the immediate ’sons’ of an artwork, or by other words, it’s variations. And if I don’t keep the ‘parent’ field, the only way I can get them is by getting the whole tree bellow the ‘parent’ node I want, and then process it to retrieve the nodes I really want.

I haven’t decided yet how I’m going to manage the deletion of artwork in the versioning system. But the I’m thinking in keeping the version node flagged as deleted if the corresponding artwork was deleted. Since I pictured a few cases in which I don’t know how to handle the removal of nodes, this seems to me the best solution for now. Later if I want I can implement a purging method for the flagged nodes.

So what have I been doing during the last weeks?

To start let me tell you about a ‘under-heavy-development’ progress table I addded to live.gnome so I have a clearer way to let others know what I have done so far and what is missing. Never the less, please remember it is still being built. As the times goes by I will be adding more tasks.

Anyway, returning to the subject. I can consider the moderation process complete. The features it is lacking will be added when the components they depend on are complete.

Moderators can already vote in favor or against a users’ work. If the global rating of that work reaches the imposed limits, it will be automatically moved to the public gallery (in case it was accepted) or back to the draft folder of the user (in case it was rejected). The only part of it missing is letting the user know that his work was accepted/rejected. Easily done when I have an internal message system implemented.

Users allowed to do so can now change others users permissions in the administrative interface and soon enough user edition will be also available.

Next steps will be to complete the submission process. This is a kind of boring task because it has a lot of forms to be handled. Since I’ve only completed the background submission process and I’m still missing Theme and Screenshot uploads I better finish this before starting any other part.

Other thing that is bothering me is that I’m slacking a bit in what concerns the looks. I think I is better to spend some time working in the layout of the whole page and specify a base style-sheet. And with this I mean define all the rules about links, paragraphs, headings, notices, etc.

Well, let me go back to work

All the authentication and registration process is up and running. Already coded the moderation model and all the ones related with the voting process. And currently I’m working in the artwork submission process and all the post-processing needed( create image variations, check packages validity, etc). After this is complete I will be able to fully integrate the moderation process in the system.

After friday I won’t have any more exams to bother with, so hopefully the development rate of AGO will increase hugely!

So the latest update still is related with authentication.
Registration process was finally implemented as well as the use of openID.

In case of users having an openID account they can use it to login in AGO. In case it is their first time, they’ll be asked to register.
The other users work like in any other system, register an username, login and everything is set to go.

Ok, so current code is lacking some features like password request and account activation, so I’ll be working on that during the next days.

There are plans to implement internationalization so I’ll also be looking at in a near feature, before having hundred of messages lines needing to be manually changed.
Btw, I’m thinking on using php gettext. If you have any better idea, please let me know.

So what have I done so far?
Well, I started coding an Authentication library. As I mentioned in my proposal, I’ve implemented some basic ACL.
It isn’t much, I know, but more is to come in next few days!

In response to the problem I’ve already gather several ideas among the community and tried to compile what I think is a good solution to the problem.

• Every work should be submitted to an initial moderation process where it is voted by several moderators if it is accepted or not
• After being accepted, it will be made fully public. Users can now vote on it. This votes will decide if a work will stay in the system or not.
• In case of having a negative rating for a certain period of time it is removed from the public gallery and moved to the author’s draft folder.
• The most active artwork developers are perfect candidates to become moderators. That can be seen as a way to recognize and award their commitment to the community

You’ll find a complete description of the process in here.

However I’m not fully happy with this solution. So if you have any suggestion, please, do tell.

Thomas(my mentor) and I have been slowly planning the database schema. Being this probably one of the most important steps in the whole process there’s no need to rush things up.
All ideas can be found in the gnome wiki where I’m updating previous ideas aswell as adding new ones.

But let’s explain some ideas, that’s why this page exists.

Authentication
Implement ACL to manage user permissions in the system functionalies seems to be a good option since it let’s easily change user rights whenever needed. Not that we need to be changing constantly but we are looking for a expandable system, so let’s not hardcode too much basic features. In later development this can help to speed up code writing.

XML+RPC
Ok. So one of the features I’d love to implement would be this one. This integrates art.gnome.org with 3rd party applications, which can be beneficial to everyone.
If you aren’t familiar with XML+RPC, it would allow us to launch an API so 3rd party applications could interact with AGO. A possible example is to download backgrounds, themes, icon sets directly to a GNOME Desktop using a small application based on AGO API.

That’s all for now.

If you have an idea you think can help the project or just want to comment about, please do. Every feedback is welcomed.

My mentoring organization will be GNOME Foundation and my application was about developing art.gnome.org Version 3(AGO3).
So for the next three months I’ll be developing AGO3 and I’ll be using this page as a log to my experience with the SOC program.

So, about the project:
art.gnome.org is an artwork site for GNOME’s Community. Users can submit their artwork and share it.
This new version to be developed will give new life to the project, where users will have a major role in what content they want to see. Let’s say, a more web 2.0 view
Anyway, you can read everything about it in my SOC proposal