Archive for the ‘planning’ Category

So this was the subject I’ve spent a big chunk of my day thinking in!

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 this has been my major concern in the last few days.
One of AGOv3 objectives is to be an hight quality artwork repository for GNOME desktop. Thus, there is the need for moderation. Since AGO’s development community is short on staff we need to find a efficient way to have submissions checked out. On the other hand the community should also have the opportunity to say what they think should or shouldn’t be accepted.

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.

Well, in the past days I’ve been idling in #gnome-art @ irc.gnome.org. I haven’t had the opportunity to meet much of the community and I definitely should do that. They certainly have valuable ideias to the project.

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.