Since all cookies are made on my home computer, I don't want to re-register using another email account..
I should probably explain that bit a little more. I proposed to the LiveJournal developers a long while back that a new form of authentication was possible based on just cookies and a user's email address. Since almost everyone uses IMAP or web-based email services like Hotmail, Gmail, Yahoo, etc. It's safe to require reauthentication via the user's email if they are at a "new" location. But where we disagreed was security. I thought it would be good to integrate the users Browser Agent string into the MD5 checksum of the cookie, and they wanted to use some other scheme.
Anyway, this method would not require re-registration, It would just want users to verify they are the ones that own a particular email account associated with the user name. Additionally, there would be a read-only option, so you wouldn't have to log in or require the end-user of Open Builder-based software to log in. Just the developers.
Adding the chance to upload files and scripts is very good, would it also be possible to add more options like posting the new/updated script on the forums and having a service to upload images to post?
Images is another idea. Maybe a developer could post an optional screenshot of their build and it'd be listed, but this wouldn't be needed for .script files, I don't think.
Jaclaz, raised a very good point, XML is excellent for ease of machine language and web applications, but it's not very human readable to most users. People should not need to edit these manually..
There would be no man-made XML, it'd just be capable of providing an xml-based interface if someone wanted it. (The only reason I can think of is so that Open Builder could *pull* scripts and builds/projects from this web app.
Adding a web browser based from IE on a delphi application is simple enough, it would also be nice to provide a good place where everyone can catch up with the latest news and updates on the boot land site, perhaps the script repository could also act as a web portal?
That's something I'll maybe have to add in for a version 2.0 or something. Also, assuming I get all the kinks worked out of it, I could open the source, so that people could host their own .script repository as well, but I think that ideally we'd want to have *one* location for developers to place their scripts for at least a while. It'd also make it easier on coding, but Nuno could offer an option to change the server if you wanted to host your own (in case my site went down, for example). Or maybe we could have two sites, both mirroring each other.
It would be good if it could also import RSS feeds (since boot-land.net is now updating RSS feeds every 1 minute with the latest 5 replied topics..), and I know I'd sure like to have this window on openbuilder showing me the latest replies, news/informations and popular/new or updated scripts.
This almost sounds like replacing the forums. I mean, that capability could maybe be built in, but it'd probably be for like a version 2.0 or something. Right now I just want to get the repository done. What we have in 047 should hold us over for now.
For the versioning: I kinda feel we should adopt the [major].[minor].[patch] versioning template (as found in the linux kernel f.ex). To bring this further, we could 'force' people into following the linux kernel paradigm: beta/untested versions have odd minor version numbers, stable/tested versions have even minor version numbers. Also, the major number only changes if there is an architectural change
That something we could adopt in a bit, but for now, I just want to get the first version done. We could look at "rules" for it maybe later.
On that note: viewed scripts could/should report which builds they explicitly support/are designed for (and, optionally, do not work with). Including version number, of course.
That's part of the idea with this. If the scripts are placed online right, someone could easily find the right version of a particular script that works with the right build. Ideally, in fact, nothing would ever be deleted, so there'd be no worry about a version of say, microPE that you have now not working quite right in the future. So say a meg is cut off from one version to the next but it requires a font that you don't particularly like, then you could keep using the older version till someone made a .script that added the font back in.
The point of this is to allow us ultimately to "modularize" Windows XP/2003 components so that the end user could basically be given a checklist of things they want/don't want and know they are building exactly what they want at the smallest size possible. Linux LIVE cds *kind of* have this, but they are working from the ground up. Since XP is a final product and we are taking away from it, I think this method works best in the long run.
I am not sure how usefull searching on a date range will be. I propose searching on script type as another option anyway.
Sounds good. That'd probably be a good idea. Also, I see the typo too, I'll be sure to fix that as I'm working on it.
A second thing an online .script repository would enforce: wellformed scripts. Not that there are many pitfalls ATM
There aren't any huge problems right now. 047 addressed most of what I'm trying to do, I'm just also trying to provide the capability of storing all the old versions so that when new ones come out, people don't have to jump into it, or if they do, it'll be as testing, not comitting them to the new version without betaing it.
@Yorn: i had a thought: integrated svn support? this should probably be hidden away in an advanced drop-down box or something. with input fields to select server, server path, username and password. Also a checkbosx for commit or import... this would be kewl, but maybe a bit advanced to begin with
You're definitely catching on to what I'm working towards. It'd be something where people could ideally have the "Working" project and then for those willing to, the latest and greatest "Beta" project. SVN support would take a while to do, but that is basically what I am trying to duplicate here, a version control system so the end-user gets what they want, and the developers and tweakers can change it up to whatever they want.