2005-08-10, 00:01
hi,
most of you probably know that i will be going away next saturday and won't work on xbox related stuff for almost a year at least. thus i have a wish that people carry on working on the site and the scripts belonging to the site, as i do feel it has come a long way and is useful to people (at least one may hope so).
so, if you have looked at the code for the installer, you might notice that there are a lot of code for a local browser in there. in fact, the backbone of the code is almost complete. i will now try to explain a bit how it works (if i can remember...coded this part in june). it first gets the directory list in q:\\scripts\\ . then it visits every directory looking for a .py file. if that is found, we know that we're dealing with a script. then we introduce the scripts specs (which are still floating in the air...but let's leave that for later). we want to know if the script is specs-compliant, so it checks for a script.xml in that dir. if that is found, it parses that xml and returns data from it. however, if no xml is found, the data is still created, but it uses directory name as script name and rest of info in the object is set to "unknown".
all code to do this is in there already, only thing needs tweaking is the xml parsing part to match whatever script spec chosen. all this returns one object in the end - a list. this list contains multiple dictionaries, one for each script. out of this dictionary you can read e.g locallist[0]['name'] to get name of first script. as you can see there isn't much work left to do, since most already is done (i believe...my memory could fool me though).
the way i had planned on doing this was making it one big script containing both a browser and an installer, which you could switch inbetween them. an notifier to notify for new versions of scripts would of course be nice, and is possible and not too hard either, but it complicates things a bit. the easiest way of handling this would be only allow updating on scripts that use the scripts specs, since then you can read date out of xml. to allow non-specs scripts to get updated this way you could save an xml with scriptd id (all scripts on site has an id number) along with the date fetched from site. then you would know what date the local copy was of.
this should provide some background to the script, as i really wish that it could develop into a full-fledged browser, with auto-updating scripts, thumbnails viewing and whatnot. please ask question and show your interest in this thread if there's any
i will release all graphics files i have lying on my disk related to this project shortly..(on the scriptservice site). thanks for taking your time reading all this.
most of you probably know that i will be going away next saturday and won't work on xbox related stuff for almost a year at least. thus i have a wish that people carry on working on the site and the scripts belonging to the site, as i do feel it has come a long way and is useful to people (at least one may hope so).
so, if you have looked at the code for the installer, you might notice that there are a lot of code for a local browser in there. in fact, the backbone of the code is almost complete. i will now try to explain a bit how it works (if i can remember...coded this part in june). it first gets the directory list in q:\\scripts\\ . then it visits every directory looking for a .py file. if that is found, we know that we're dealing with a script. then we introduce the scripts specs (which are still floating in the air...but let's leave that for later). we want to know if the script is specs-compliant, so it checks for a script.xml in that dir. if that is found, it parses that xml and returns data from it. however, if no xml is found, the data is still created, but it uses directory name as script name and rest of info in the object is set to "unknown".
all code to do this is in there already, only thing needs tweaking is the xml parsing part to match whatever script spec chosen. all this returns one object in the end - a list. this list contains multiple dictionaries, one for each script. out of this dictionary you can read e.g locallist[0]['name'] to get name of first script. as you can see there isn't much work left to do, since most already is done (i believe...my memory could fool me though).
the way i had planned on doing this was making it one big script containing both a browser and an installer, which you could switch inbetween them. an notifier to notify for new versions of scripts would of course be nice, and is possible and not too hard either, but it complicates things a bit. the easiest way of handling this would be only allow updating on scripts that use the scripts specs, since then you can read date out of xml. to allow non-specs scripts to get updated this way you could save an xml with scriptd id (all scripts on site has an id number) along with the date fetched from site. then you would know what date the local copy was of.
this should provide some background to the script, as i really wish that it could develop into a full-fledged browser, with auto-updating scripts, thumbnails viewing and whatnot. please ask question and show your interest in this thread if there's any
i will release all graphics files i have lying on my disk related to this project shortly..(on the scriptservice site). thanks for taking your time reading all this.
(i take it that's the american way of typing dates)