Jump to content











Photo
- - - - -

Online .SCRIPT repository


  • Please log in to reply
12 replies to this topic

#1 Yorn

Yorn

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:United States

Posted 28 July 2006 - 01:01 PM

Hey guys. I'm a PHP coder and have been recently given a really large space along with good bandwidth in a hosting package for a domain I'm running. I'm working on the idea of having an online repository where OpenBuilder itself or individual people could store .SCRIPT files or Projects (which in this I call Builds). Anyway, Nuno and I think it'd probably be best integrated into Open Builder, but it'd be primarily a web app. It would take some time to code, but after I get moved, I think I could have it done by the middle of next month.

Attached is a .zip file with two text files that are designed to be read side-by-side. I want to get some opinions on what people think, Some of the coding time could be significantly reduced if I just implemented it as an XML-based web app that only interacted with Open Builder itself. That would mean developers wouldn't have a web interface, but I'm thinking that maybe you wouldn't really need one.

This does change some of the current architecture of script development, but I'm open to suggestions and in fact, if you see something you do not like, PLEASE MENTION IT HERE. I'm 100% for things that could be changed and would rather have negative feedback than no feedback, so please take a look at it and tell me what you don't like.

Also, I haven't sent these to you yet, Nuno, but if you could tell me what could or couldn't be done as far as XML interfacing with Delphi apps, that'd be good to know too. I'm not that great of a coder, but I know PHP/MySQL scripting.

Attached Files



#2 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 28 July 2006 - 01:38 PM

my two cents, and I am probably the wrong person to actually give technical advice on this, but WHY one should use XML when a normal TXT file is MORE than enough?

Text files can be READ, XML has to be PARSED, yes I know that it has a lot of "smart" features, but I have completely failed to find any of them actually useful.

jaclaz

#3 Yorn

Yorn

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:United States

Posted 28 July 2006 - 02:52 PM

I'm sorry, I didn't properly explain that. The .SCRIPT files will remain that. The interface between the .SCRIPT Depository and Open Builder would be XML.

#4 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 28 July 2006 - 03:05 PM

I think the idea is good, I've just read both proposed site text files.


One "future" question:

I've just registered with my email at my home computer. I'm now on a public net acess or in my friend's pc, how do I login? :P


Since all cookies are made on my home computer, I don't want to re-register using another email account..



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?


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..


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?

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.

Just to keep in touch with things whenever I'm using the program.. :P

#5 Draugen

Draugen

    Frequent Member

  • .script developer
  • 147 posts
  • Location:South of Heaven

Posted 28 July 2006 - 04:34 PM

@ yorn: this seems snacksy :P good job.

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 - e.g, something changes in the base scripts of a project/build, making 'drop-in' add-ons incompatible (Ove's Explorer plugin is a good example of such an add-on script to nuno's scriptpack), or the "inner magic" of the script changes significantly. The last bit is rather subjective though :P

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.

I am not sure how usefull searching on a date range will be. I propose searching on script type as another option anyway.

I also found a typo in 'screens.txt' at line 110: PostKernel is incorrectly labeled as PostDriver :P nothing bad though.

Also, XML is the way to go. XHTML is, well, XML (although purists deabte wether or not it should be used for the WWW. Internet explorer chokes on content-type: application/xhtml+xml - and this is actually needed i some circumstances. MathML for exmple. W3C recommends this too.). RSS feeds are XML. XML is one of the best ways to transport data i know of. For storing data, however, i prefer a relational database :P (how would one normalize a set of XML files? :P )

@nuno: I am sure there is an XML component for delphi/objectpascal somewhere. I would hate to see Openbuilder being bloated with an internal web browser. Just a simlpe mechanism to check for updates and/or new scripts is enough IMHO. Perhaps the ability to upload scripts too. In this case, much of the process could be automated by parsing the [main] section of a script (this, ofcourse, applies to the web interface as well).

A second thing an online .script repository would enforce: wellformed scripts. Not that there are many pitfalls ATM :P.

.script attribute proposal, nuno: another [main] value: depends = [delimited list of builds and (optional) scripts this scripts depends on]. Example:

[main]

depends = micrope\driver_net-tcpip;micrope\service_lanmanserver|nanoxp\network_full

\ separates a script from a project. Everything before the \ (from = or ; or | )is taken to be a project name. everything after the \ is taken to be a script name (up to an eventual ; or |).

; separates mandatory requirements. ALL of these have to be met.

| separates replacement requirements. The script works if either one of the lists (not neccesarily just two) of needed scripts are met (between | and |).

i just realized that parsing this from a file requires a shitload of pattern matching. This could take a while to implement :P

Some ideas :P hope they are usefull...

#6 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 28 July 2006 - 05:09 PM

.script attribute proposal, nuno: another [main] value: depends = [delimited list of builds and (optional) scripts this scripts depends on]. Example:

[main]

depends = micrope\driver_net-tcpip;micrope\service_lanmanserver|nanoxp\network_full


I agree to this suggestion. I'm currently thinking about my ProjectInfo script to give warnings when a necessary script is not yet executed.

Peter

#7 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 28 July 2006 - 05:49 PM

mmmh :P

I think I was too fast with my answer.

Martin 'draugen' Anderse means the physical dependency:
A certain object can work correctly only when one or more other objects are present and of the correct version.

I meant the logical dependency inside a project:
It does not make sence to run a script, if one ore more necessary other scripts are not yet executed.

Nevertheless: I still agree to the suggestion. Maybe helpful for the update logic.


Peter

#8 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 28 July 2006 - 08:01 PM

Xml support shouldn't be hard, my main concern is making things just too complicated for most people..

Adding revisioning, patches, paired, unstable, major and minor version numbers is fine by me.. but imagine others trying to figure how to follow all these rules and script dependencies..


You may notice that since 047 each script can be updated individually, and developers can make their own update service in order to provide a faster way to bugfix and upload the changes. It only uses decimal numbers to distinguish from the last update: 1, 2, 3, 4, 5, 6.. it's not linux standard, but it's simple enough for everyone to memorize and use..

If you make a derivative branch script that was previously edited/created by other developers - change the name or let your imagination run wild.. :P


As simple as making an update service may seem, it's not yet been seen in action around here, it's still easier to just post new bugfixed releases on the discussion post. (even I prefer to do it this way.. )

I intend to add an automatic updates check on 048, just for those that don't keep track of discussion topics that will still have their scripts updated if they wish - the same goes for the application itself, this will save time and allow everyone to be working the latest versions.


Checking for dependencies is also a good idea, but it would also make the [main] section even more filled with all sort of definitions.. I would surely prefer to see it replaced in the future by a RUN command with parameters - that could check on an external script something like:

Run,%Archive%\Build\RunCheck.script,CheckIfExecuted,%projectdir%\Build\driver_net-tcpip.script
Would link to a small routine that could check if wether %projectdir%\Build\driver_net-tcpip.script was run or not.

If this is not the case - then show a message "This script needs %projectdir%\Build\driver_net-tcpip.script to be enabled before continuing" and exit.. :P

This way only critical scripts can choose to have this added along with other checks (if a %targetdir% exists, ...)

I also agree that there should be a minimum build support switch on scripts to avoid running newer scripts on older .script interpreters, I will work on this perhaps after 048.. :P


Thanks for all these good ideas, but I'm still afraid that they might limit new scripts only to those who understand these all these rules, perhaps it would still be wiser to make these scripts more "clean" and readable for everyone, otherwise it won't be fun at all to make them.. :P


I'll do some googling around and then I'll give more feedback.. :P

#9 Draugen

Draugen

    Frequent Member

  • .script developer
  • 147 posts
  • Location:South of Heaven

Posted 29 July 2006 - 03:05 PM

Xml support shouldn't be hard, my main concern is making things just too complicated for most people..


'Most people' should not know it is there :P.

Adding revisioning, patches, paired, unstable, major and minor version numbers is fine by me.. but imagine others trying to figure how to follow all these rules and script dependencies..
You may notice that since 047 each script can be updated individually, and developers can make their own update service in order to provide a faster way to bugfix and upload the changes. It only uses decimal numbers to distinguish from the last update: 1, 2, 3, 4, 5, 6.. it's not linux standard, but it's simple enough for everyone to memorize and use..

but there's the thing. I feel it is TOO simple. i really like being able to tell at a glance wether a script/program is considered stable or not. Or wether things that worked previously can be expected to still work.

If you make a derivative branch script that was previously edited/created by other developers - change the name or let your imagination run wild.. :P

well, that kinda is implicit. even something as simple as ove_ramdrive_draugenmod.script will do

As simple as making an update service may seem, it's not yet been seen in action around here, it's still easier to just post new bugfixed releases on the discussion post. (even I prefer to do it this way.. )

I propose doing both. perhaps the script repsitory can interface with IPB and add such posts automatically?

... snip ...

Checking for dependencies is also a good idea, but it would also make the [main] section even more filled with all sort of definitions.. I would surely prefer to see it replaced in the future by a RUN command with parameters - that could check on an external script something like:

Run,%Archive%\Build\RunCheck.script,CheckIfExecuted,%projectdir%\Build\driver_net-tcpip.script
Would link to a small routine that could check if wether %projectdir%\Build\driver_net-tcpip.script was run or not.

If this is not the case - then show a message "This script needs %projectdir%\Build\driver_net-tcpip.script to be enabled before continuing" and exit.. :P

This way only critical scripts can choose to have this added along with other checks (if a %targetdir% exists, ...)

IMHO, it is the interpreter's job to keep track of wether a script has been run. a simple 1 (yes) or 0 (no) temp variable will do. Then one can do:
If,ScriptExecuted,<someproject>\<somescript>,&#91;do something&#93;
.

I also agree that there should be a minimum build support switch on scripts to avoid running newer scripts on older .script interpreters, I will work on this perhaps after 048.. :P


I used builds in my post the same way Yorn used them: interchangeably with projects. but, indeed. The ability to check for version of openbuilder is good :P

Thanks for all these good ideas, but I'm still afraid that they might limit new scripts only to those who understand these all these rules, perhaps it would still be wiser to make these scripts more "clean" and readable for everyone, otherwise it won't be fun at all to make them.. :P
I'll do some googling around and then I'll give more feedback.. :P

Even though things should be simple (i'm quite anal about that really :P ) let's nott be afraid of USEFUL functionality. But one should always beware featuritis.

@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 :P

--martin (who is comfortable with being called 'draugen' :P )

#10 Yorn

Yorn

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:United States

Posted 29 July 2006 - 08:47 PM

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.

#11 Draugen

Draugen

    Frequent Member

  • .script developer
  • 147 posts
  • Location:South of Heaven

Posted 30 July 2006 - 02:53 PM

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.


Good we're on the same page then :P

i was just wondering about svn support (maybe even CVS too) since i store the micrope files in an SVN server of my own (it is very convenient to have the latest copy of a project only a 'svn co ...' away)... and since SVN interfaces nicely with WebDAV, this should not be TOO tecnical either...

#12 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 30 July 2006 - 02:58 PM

I'm really looking forward to see the results.. :P

#13 Yorn

Yorn

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:United States

Posted 03 August 2006 - 02:41 PM

I also found a typo in 'screens.txt' at line 110: PostKernel is incorrectly labeled as PostDriver nothing bad though.


Fixed this locally. I'll have an updated list of things to look at by the end of the week.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users