UUIDs

This week was spent working on trying to use UUIDs to identify the properties that we want to include in the AST nodes. I am not completely familiar with the concept of UUIDs, so I spent some of the week learning about how identification pointers like UUIDs, GUIDs, and auto-incremented work.

UUIDs and GUIDs seemed to be essentially the same thing from the various sources I looked at about them. The primary difference it seemed was that UUIDs are universally unique, while GUIDs are only globally unique. This basically just means that the chance of one being duplicated is smaller with UUIDs. However, both are 128 bits (32 hex digits) and have an incredibly low chance of being duplicated, which is what makes them excellent identifiers. However, one disadvantage is that they add a huge overhead to any data that uses them. We are currently using UUIDs for identifying the AST nodes. I am assuming that this is because we want the code to all be remixable. If a section of code is taken from one world and put in another world, the UUID can be used to identify the original code. Furthermore, since the AST nodes are created in each users personal computer when they write their programs, the database is not centralized. UUIDs help prevent any confusion by making each AST node unique.

Auto-incrementing identifiers are very simple. The id is an integer and every time a new object is created, the integer is incremented. This has advantages in the fact that the numbers are very easy to use and debug. However, it is difficult to merge databases because there could be a number of different items that all have the same identification number pointing to it. As far as I can tell, we are currently using auto-incrementing identifiers to mark worlds and users. This makes sense because it is all being created in the centralized database online and there is no database merging necessary between worlds and users.

Kyle and I were originally thinking of having a Remix ID table on the community side that contained the following information: Remix ID, User ID, World ID, and AST Node. Furthermore, each node will need to be tagged with how the code was generated and whether or not it has been modified. We determined that there were two main ways code could be generated: Passive (by the Looking Glass system) and Active (by the user). Active code generation can have further properties on whether the user was assisted (Kyle's tutorials), who the user is, and whether or not the code is duplicated. If the code is duplicated, the duplication has several properties as well. Whether the duplicated code is from a remix or a copy (clipboard). The duplicated information would also need to provide an "origin world" id and an "origin AST node" id.

Looking at the information that needs to be added to the nodes, I don't think that just taking four digits from UUID already associated with each AST node will be enough. While it purposely choosing four digits to represent the information, I think there is more information than can be represented iin four digits. I think a better plan of action would be to continue what Kyle and I had thought of this summer with each node having an additional property of "Origin" which will describe all the features that we need for remix. These plans for the most part were determined by Kyle and I over the summer, but I need to learn how to implement them.

Using UUIDs to code for the information in remix.

http://en.wikipedia.org/wiki/Globally_unique_identifier

http://en.wikipedia.org/wiki/Universally_unique_identifier

http://debuggable.com/posts/why-uuids:48c906cc-7a6c-4f22-9e20-6ffd4834cda3

http://betterexplained.com/articles/the-quick-guide-to-guids/