From: russ
Date: Fri Apr 30 12:57:56 MST 2004
Subject: Object-Orientedness

Object Orientedness You don't have to derive an entirely new class every time that you want something new. Instead, you can declare a class to be derived from another class. For instance, suppose you wanted to have your own thing that was a lot like a blog but included something new, like, for instance, you wanted each blog to have a single picture attached. Then you could write something like this: class BlogWithPicture : Blog { Picture picture; function Display() { Blog.Display() print picture } } You note in the class declaration that it says that there is a new class, called "BlogWithPicture", which is derived from "Blog". That means it includes everything from Blog, plus some more. So, like Blog, it includes the fields "subject," "date," and "text," but it also includes a Picture field called "picture." The form for this class automatically gets a new field where the user can upload this picture. Finally, the class declares a new Display() function. The first thing that it does is to display everything that a normal Blog does (with Blog.Display()). Then it displays the picture that was uploaded.

Edit this response
Write a response Email the author

From: russ
Date: Fri Apr 30 13:07:09 MST 2004
Subject: Nesting

From: russ
Date: Mon May  3 15:01:01 MST 2004
Subject: Versioning

One of the common things that happens with this website is that we change things. We add new features, or sometimes remove old ones. More often, we just update the look of things. You could, of course, create a new class every time that you wanted to change something, and make it a child of the old version. But then it becomes harder to figure out where everything should show up in LatestUploads and stuff like that. So, what I am thinking about is a versioning system where you can modify an existing class. The old data, which was uploaded using the old class, can still be viewed using the old version of the class. But new uploads will use the new class. They should be able to interact just fine. Now, what happens when you aren't really changing anything about the class itself, you just want to change how it looks online a bit? You don't really want to upload a whole class, you just want to change one of the functions. Moreover, if you are doing this it is likely that you want this change to affect old uploads; you don't want this just to show up in new uploads. This implies that there is a distinction between the version of the data in a class and the version of the display functions. Perhaps they should be uploaded separately? Perhaps what should happen is that you write the data structures, then you write the various forms later. More thoughts coming....

Edit this response
Write a response Email the author

From: russ
Date: Mon May  3 17:43:59 MST 2004
Subject: Security/Storage Paradigm

The webmaster continues to mumble to himself.... I don't want somebody to steal/guess somebody else's password and use it to delete/modify lots of stuff posted by the other guy. Yet I want somebody to be able to modify/remove/rename things they post. This is how the language will solve the problem: First of all, at the low level, nothing will be deletable. Once you upload something, it cannot be edited or removed. (Of course, the webmaster can break all the rules...) However, users will still be able to do a "remove." What will happen when they "remove" something is that the connections which cause it to show up on the website will be removed, or else some sort of flag will be set up which will tell the website not to index it. So, although it will be sitting on the hard drive of the webserver, it will not be visible to the users of the website. What this means is that users will be able to remove things from the website, but the webmaster will be able to restore stuff if something goes wrong. In the last year of so of adminning this site, I've found that it's not just the raw data that is important to maintain. The metadata (like the last-modified date, the links to responses, etc.) is also important to keep accurate, and I want to protect it with the same security features. If some hacker can come in and delete (or undelete) huge amounts of stuff on the website, and I then have to fix it all by hand, that's a Bad Thing. Happily, this is doable with the system I'm devising here. The metadata of the website will be protected just like the base data. So if there is a record which shows the current list of uploaded blogs, you can't delete that record. What you can do is edit (or make invisible) that record, but it still stays around in the backup copies of the website. The way this happens is that when you edit things, you don't really edit or remove the old data. Instead, the old record is stored inside a "prev" field of the current record. Typically, a class's Display() function will only display the latest version, but it is possible to show old ones as well. So, for example, when you upload a new class type (see Versioning above), you will be creating a new class record, but the old class record will still be available through the "prev" field. Now, when something refers to something else in the website (such as how an uploaded object refers to the class which defines it), you need to decide whether that link is to a very particular version of the thing, or to the latest version. In the example where a certain upload (say, a Blog) points to the class which defines it (the Blog class), you want to point to a specific version of Blog. Even if the Blog class is updated, that specific blog you uploaded will always be controlled by the old code. On the other hand, if the thing you're uploading is something that controls how the website looks (such as the modifiable Links section on the top of this website), then you want to have everything refer to the most recent version; when you upload a new version, you want everything to automatically point to the new one. I haven't figured out exactly how I'm going to do this yet. However, the website language will allow for both types of references; ones which are tied to a very particular version of an upload, and ones which follow the upload as it gets updated.

Edit this response
Write a response Email the author

From: Suki
Date: Tue May  4 09:28:21 MST 2004
Subject: Response

From: russ
Date: Tue May  4 12:58:52 MST 2004
Subject: IMG tag

From: Suki
Date: Tue May  4 16:24:39 MST 2004
Subject: Groovy

From: benjipark
Date: Wed May  5 02:52:02 MST 2004
Subject: Classes and their ponderings

From: russ
Date: Wed May  5 13:44:08 MST 2004
Subject: Yep!

From: russ
Date: Wed May  5 22:18:20 MST 2004
Subject: Data Format

The data format used in this system will be, essentially, a database. Each different type of upload has its own table with its own different fields. Each uploaded item is a record in the table. The database is a relational database. So, if you have an upload class which uses other upload classes as fields (and most will), then uploading something will actually upload multiple records. There will be a record for the main upload. There will also be records for each of the constituent fields. Links in the main upload will point to the appropriate records for the fields. Only the main upload will get listed in Latest Uploads. I figure that (probably) you won't necessarily have a different table for every upload class you've ever created. Instead, the website will create a new table only when the actually data format changes. This further reinforces the idea that the data format of an upload class should be separated from its various functions.

Edit this response
Write a response Email the author

From: russ
Date: Wed May  5 22:37:40 MST 2004
Subject: Cheapo Database