So, after looking at the vast (and increasing) number of *.js files in the exec
directory which are not intended to be executed but are instead intended to be
load()ed by some other script, I've started thinking about a library system for
the JS load() method. My initial thoughts are something like the following: ...
This change would impact all JS files, but with reasonable defaults, the impact
could be mitigated.
Comments?
Etc.
This change would impact all JS files, but with reasonable defaults, the impact
could be mitigated.
Comments?
So, after looking at the vast (and increasing) number of *.js files in the exec directory which are not intended to be executed but are instead intended to be load()ed by some other script, I've started thinking about a library system for the JS load() method. My initial thoughts are something like the following:
- There be some array of search paths for load() which can be added to by a
script. Additions can be at either end of the array, and these paths can be
either absolute or relative.
- If the path is absolute, only a single directory will be searched.
- If the path is relative, two directories will be searched, a "mods"
style directory and a stock directory. The question of if these belong
under a shared parent directory (ie: jslibs) or under the exec/mods
directory is an open question.
- Some way of specifying an initial list (in the ini file)
You would end up then with something like this:
jslibs/
std/
sbbs/
ars_defs.js
nodedefs.js
sbbsdefs.js
sockdefs.js
uifcdefs.js
irc/
irc-default.js
irclib.js
ircd/
ircd_channel.js
ircd_server.js
ircd_unreg.js
ircd_user.js
mods/
irc/
irc-cyan.js
Etc.
This change would impact all JS files, but with reasonable defaults, the impact could be mitigated.
Comments?
This change would impact all JS files, but with reasonable defaults, the impact could be mitigated.
Comments?
I would think having an ../scripts/ directory along side of exec would be appropriate, perhaps modify/remove the scfg setting for a mods dir... as a base script path, where relative script paths are loaded from as a base, followed by a search list as you suggested...
../scripts/{input}
../scripts/mods/{input}
../mods/{input}
../scripts/std/{input}
../exec/{input}
etc..
I would think having an ../scripts/ directory along side of exec would be appropriate, perhaps modify/remove the scfg setting for a mods dir... as a base script path, where relative script paths are loaded from as a base, followed by a search list as you suggested...
../scripts/{input}
../scripts/mods/{input}
../mods/{input}
../scripts/std/{input}
../exec/{input}
exec/
login.js
logon.js
listserver.js
nntpservice.js
etc.
exec/include
*defs.js
*lib.js
*util.js
where 'exec' can be replaced with 'mods' (and is searched first), as is the current scheme.
If you're talking about trying to make things more "findable" then I'm all for it, though how would that affect the few of us who have searched
through the mess finding things to modify currently.. and have these things modified to quite an extent?
I actually like it the way it is, except the fact that there's a few things that aren't moddable via text.dat that are only in the source code, but they're STRINGS that should be able to be modified and saved, and not hopefully lost by the next update from CVS.
The easiest thing though would be to modify the default set of search paths to place the mods directoy *first*. This would fix all the issues, but leave your mods dir cluttered.
Actually, maybe mods first would be part of the default...
Part of the problem is that when I want to have different files load()ed as part of a script outside of the exec directory (such as with TradeWars), I need to create the absolute path to the file on every load. Rather than saying: load("users.js");
I need to say:
load(path_to_door+"/users.js");
Which is kind of silly.
So, after looking at the vast (and increasing) number of *.js files in the execi think that the problem is the absolute path
directory which are not intended to be executed but are instead intended to be
load()ed by some other script, I've started thinking about a library system for
the JS load() method. My initial thoughts are something like the following:
- There be some array of search paths for load() which can be added to by a
script. Additions can be at either end of the array, and these paths can be
either absolute or relative.
- If the path is absolute, only a single directory will be searched.
- If the path is relative, two directories will be searched, a "mods"
style directory and a stock directory. The question of if these belong
under a shared parent directory (ie: jslibs) or under the exec/mods
directory is an open question.
- Some way of specifying an initial list (in the ini file)
You would end up then with something like this:
jslibs/
std/
sbbs/
ars_defs.js
nodedefs.js
sbbsdefs.js
sockdefs.js
uifcdefs.js
irc/
irc-default.js
irclib.js
ircd/
ircd_channel.js
ircd_server.js
ircd_unreg.js
ircd_user.js
mods/
irc/
irc-cyan.js
Etc.
This change would impact all JS files, but with reasonable defaults, the impact
could be mitigated.
Comments?
---
Synchronet - Jump on the Web 0.2 bandwagon!
---
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
The easiest thing though would be to modify the default set of search paths to
place the mods directoy *first*. This would fix all the issues, but leave your
mods dir cluttered.
Actually, maybe mods first would be part of the default...
On 8/7/2009 10:40 AM, Deuce wrote:
The easiest thing though would be to modify the default set of search
paths to
place the mods directoy *first*. This would fix all the issues, but
leave your
mods dir cluttered.
Also, per my suggestion befor, I think that ../scripts/std/ or ../scripts/std/libs/ vs. ../scripts/mods/ and ../scripts/mods/ may be better than the split of exec and mods currently... I think ../exec is a
bit polluted here.
Deuce escribió:
jslibs/i think that the problem is the absolute path
std/
sbbs/
ars_defs.js
nodedefs.js
sbbsdefs.js
sockdefs.js
uifcdefs.js
irc/
irc-default.js
irclib.js
ircd/
ircd_channel.js
ircd_server.js
ircd_unreg.js
ircd_user.js
mods/
irc/
irc-cyan.js
Etc.
This change would impact all JS files, but with reasonable defaults,
the impact
could be mitigated.
Comments?
--- Synchronet - Jump on the Web 0.2 bandwagon!
---
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)
i want to load("pepe.js") and this will earch in the actual path not
from exec directory
but, yes,, i agree to better order to the exec directory
So, after looking at the vast (and increasing) number of *.js files in the exec directory which are not intended to be executed but are instead intended to be load()ed by some other script, I've started thinking about a library system for the JS load() method. My initial thoughts are something like the following:
..
what about a few shortcut sequences for paths?
"!/myfile.js" becomes /sbbs/exec/myfile.js
"~/myfile.js" becomes /sbbs/mods/myfile.js
Re: load() search paths...
By: Digital Man to Deuce on Thu Aug 06 2009 04:01 pm
exec/
login.js
logon.js
listserver.js
nntpservice.js
etc.
exec/include
*defs.js
*lib.js
*util.js
where 'exec' can be replaced with 'mods' (and is searched first), as is the current scheme.
Yeah, but I like the idea of allowing it to be deeper. As for include/lib, I'm not overly fond of either one to be honest... exec/load perhaps?
I'm also very fond of the idea of adding a directory under the exec/mods
dir to group related files together... while I expect 3rd party scripts to be added to the mods directory rather than exec, a bit of grouping may
help. The question of course is how to group everything.
I'm also very fond of the idea of adding a directory under the exec/mods dir group related files together... while I expect 3rd party scripts to be added the mods directory rather than exec, a bit of grouping may help. The questi of course is how to group everything.
Magical wildcards are icky.
Used to be that 3rd party add-ons (doors, etc) were put in their own directories under the /SBBS/XTRN directory. With JS now offering another option for development of 3rd party add-ons, is it apropriate to install such add-ons under /SBBS/XTRN still? And if so, should any change to the
JS load() method cater to add-ons in that location?
Re: load() search paths...
By: Deuce to Digital Man on Fri Aug 07 2009 10:34:00
I'm also very fond of the idea of adding a directory under the exec/mods dir group related files together... while I expect 3rd party scripts to be added the mods directory rather than exec, a bit of grouping may
help. The questi of course is how to group everything.
Used to be that 3rd party add-ons (doors, etc) were put in their own directories under the /SBBS/XTRN directory. With JS now offering another option for development of 3rd party add-ons, is it apropriate to install such add-ons under /SBBS/XTRN still?
And if so, should any change to the
JS load() method cater to add-ons in that location?
Used to be that 3rd party add-ons (doors, etc) were put in their own directories under the /SBBS/XTRN directory. With JS now offering another option for development of 3rd party add-ons, is it apropriate to install such add-ons under /SBBS/XTRN still? And if so, should any change to the
JS load() method cater to add-ons in that location?
Magical wildcards are icky.
Unless speaking Perl!
Re: load() search paths...
By: Angus McLeod to Deuce on Wed Aug 12 2009 11:24 pm
Re: load() search paths...
By: Deuce to Digital Man on Fri Aug 07 2009 10:34:00
I'm also very fond of the idea of adding a directory under the exec/mo dir group related files together... while I expect 3rd party scripts t be added the mods directory rather than exec, a bit of grouping may help. The questi of course is how to group everything.
Used to be that 3rd party add-ons (doors, etc) were put in their own directories under the /SBBS/XTRN directory. With JS now offering another option for development of 3rd party add-ons, is it apropriate to install such add-ons under /SBBS/XTRN still?
It is appropriate for stand-alone JS add-ons, particulary door-type programs (e.g. games).
And if so, should any change to the
JS load() method cater to add-ons in that location?
Yes, I think Deuce's propsal would do that.
The load() method can already load/execute full (absolute) paths, but that requires knows the fullpath to the directory where the file was installed. Relative paths are assumed to be relative to the "mods" or "exec" directory (the current working directory is not relavent). The tricky part is specifyi the correct path for every load() statement and being able to dynamically ad paths to the load() search is a good idea, I think.
digital man
Snapple "Real Fact" #152:
In 1985, the fastest bicyclist was clocked at 154 mph.
Magical wildcards are icky.
Unless speaking Perl!
Even then! Perl doesn't have any additional wildcards that I'm aware of... uses csh wildcard syntax last I looked.
Sysop: | Clippy |
---|---|
Location: | Houston, TX |
Users: | 4 |
Nodes: | 4 (0 / 4) |
Uptime: | 214:35:29 |
Calls: | 1 |
Files: | 11 |
Messages: | 38,209 |