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?

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

On 8/5/2009 4:22 PM, Deuce wrote:

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?

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

--
Michael J. Ryan - http://tracker1.info/

... Children are the only form of immortality that we can be sure of.

---
■ Synchronet ■ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.com

Deuce wrote:

Etc.

This change would impact all JS files, but with reasonable defaults, the impact
could be mitigated.

Comments?

Seems reasonable to me. Anything to delineate the clutter seems good.

Thanks!

Mindless Automaton
---
■ Synchronet ■ Eldritch Clockwork BBS - eldritch.darktech.org

Re: load() search paths...
By: Deuce to All on Wed Aug 05 2009 04:22 pm

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?

I like the idea of the dynamic search-path appendage ability, allowing 3rd party scripts (e.g. games, add-ons) to (easily) store all their files in some directory other than 'exec'.

I think the default directory for most scripts should still be mods & exec. What do you think of:

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.

You could use 'libs' instead of 'include' (the name isn't that important), but I would just add one new default directory and move the lib/include type files there. I wouldn't really call it a 'library system', as libraries historically, are collections (e.g. archives) of modules with callable functions. That's not exactly describing the contents of the *defs.js, *util.js, and *lib.js files we have.

digital man

Snapple "Real Fact" #83:
Googol is a number (1 followed by 100 zeros).

Re: load() search paths...
By: Deuce to All on Wed Aug 05 2009 04:22 pm

This change would impact all JS files, but with reasonable defaults, the impact could be mitigated.

Comments?

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?

axisd


---
■ Synchronet ■ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: load() search paths...
By: Tracker1 to Deuce on Wed Aug 05 2009 08:59 pm

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

Don't listen to this guy. Have you seen his mods? Do you really need to go to /home/sbbs/mods/roughnecks/user/find/this/program/if/you/dare/haha/I/got/you/du mmy/ ?

You can do it so much easier with way less directories/subdirectories. You and Ispy just have a wierd fetish. :)

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.

I for one don't need a thousand directories and subdirectories.

axisd


---
■ Synchronet ■ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: load() search paths...
By: Tracker1 to Deuce on Wed Aug 05 2009 08:59 pm

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}

The question then becomes when it's appropriate to place a file in scripts and when it belongs in exec. My outline was basically that load() would check a set of directories in order, but exec() and friends would *only* look in mods and exec.

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

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.

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: load() search paths...
By: Access Denied to Deuce on Thu Aug 06 2009 10:10 pm

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?

Well, for that, you would want to either modify the default search path set or move them to the newly appropriate place.

I would expect that when you moved to the new exec directory and did NOT move your modified scripts to match the new layout that the file from exec/load/* would be loaded instead of the modified one. Once the modified one was placed in the correct spot, everything would woprk once more.

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

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: load() search paths...
By: Access Denied to Tracker1 on Thu Aug 06 2009 10:15 pm

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.

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.

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: load() search paths...
By: Deuce to Access Denied on Fri Aug 07 2009 10:40 am

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

I think it already checks the mods directory before exec, as that's where I put all my stuff so when I upgrade, my exec dir can get manipulated however it has to be, and it won't affect the work I've done. I like that.

axisd


---
■ Synchronet ■ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: load() search paths...
By: Deuce to Access Denied on Fri Aug 07 2009 10:43 am

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.

I see what you're saying. That would get kind of annoying. :)

axisd


---
■ Synchronet ■ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)

Deuce escribi≤:

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?

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

i think that the problem is the absolute path

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

---
■ Synchronet ■ Dock Sud BBS TLD 24 HS - http://www.docksud.com.ar - telnet://bbs.docksud.com.ar

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.

Actually, maybe mods first would be part of the default...

what about a few shortcut sequences for paths?

"!/myfile.js" becomes /sbbs/exec/myfile.js
"~/myfile.js" becomes /sbbs/mods/myfile.js

if /sbbs/xtrn/tw/main.js calls "@/myinclude.js"
it references /sbbs/xtrn/tw/myinclude.js

...

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.

--
Michael J. Ryan - http://tracker1.info/

... The only thing wrong with immortality is that it tends to go on forever.

---
■ Synchronet ■ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.com

Tracker1 wrote:

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.

i dont think the exec\ dir is polluted. i think everything in the exec
dir by default is perfectly applicable.

this is a bit of a difference of opinion but i think one should raise
caution regarding going too anal with this.

Ragnarok wrote:

Deuce escribi≤:

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!)

i think that the problem is the absolute path

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

i disagree with the 'better order' mentality.

i think making another dir for a handful of scripts will, in the long
run just pollute the synchronet dir with an overabundance of directories.

i see no reason who throwing foo* into foo/ is any better than just
having a sensible naming scheme for scripts.

Re: load() search paths...
By: Deuce to All on Wed Aug 05 2009 16:22:34

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

Well I'm sure I've contributed to the mess in ..\exec\
Just as I'm sure I'll contribute more in the future

So I agree there should be a better place to put scripts that are meant to be function/object libraries, as almost everything I've put into ..\exec\ doesn't really belong there, but has no better home at the moment.


---
■ Synchronet ■ The BRoKEN BuBBLE (MDJ.ATH.CX)

Re: Re: load() search paths...
By: Tracker1 to Deuce on Sun Aug 09 2009 08:33 pm

what about a few shortcut sequences for paths?

"!/myfile.js" becomes /sbbs/exec/myfile.js
"~/myfile.js" becomes /sbbs/mods/myfile.js

Yuck! No way. :-)

Magical wildcards are icky.

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: load() search paths...
By: Deuce to Digital Man on Fri Aug 07 2009 10:34 am

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?

Yeah, I like exec/load (and by extension, mods/load).

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.

Wouldn't that be up to the 3rd party developers? I don't know how we could enforce a grouping.

digital man

Snapple "Real Fact" #57:
You blink over 10,000,000 times a year.

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?


---
■ Synchronet ■ Making sure Jason works OK at The ANJO BBS

Re: Re: load() search paths..
By: Deuce to Tracker1 on Mon Aug 10 2009 22:39:00

Magical wildcards are icky.

Unless speaking Perl!


---
■ Synchronet ■ Making sure Jason works OK at The ANJO BBS

Re: load() search paths...
By: Angus McLeod to Deuce on Wed Aug 12 2009 23:24:00

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?

I would have put everything in /sbbs/xtrn...... but the problem is that nearly all of my programs share a lot of the same functions and scripts, so i would either have to put everything in a /sbbs/xtrn/lib folder (which means I would then have to load everything from the same) or put it in /sbbs/exec or /sbbs/mods

the /sbbs/xtrn folder isn't really ideal (in my opinion) because it is already cluttered up with game directories


---
■ Synchronet ■ The BRoKEN BuBBLE (MDJ.ATH.CX)

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/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?

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 specifying the correct path for every load() statement and being able to dynamically add 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.

Re: load() search paths...
By: Angus McLeod to Deuce on Wed Aug 12 2009 11:24 pm

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?

I've been putting my JS stuff in xtrn, not sure if it's appropriate or not.
:-)

However, there are groups of functions and objects which are usefull in a general way, but aren't used by Synchronet proper. I've been dumping these things into exec for now, but exec/load/doorkit would be my preference.

Also, I expect to add the directory that a scrip is loaded from to the beginning of the search path.

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: load() search paths..
By: Angus McLeod to Deuce on Wed Aug 12 2009 11:26 pm

Magical wildcards are icky.

Unless speaking Perl!

Even then! Perl doesn't have any additional wildcards that I'm aware of... it uses csh wildcard syntax last I looked.

---
Synchronet - Jump on the Web 0.2 bandwagon!

---
■ Synchronet ■ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: load() search paths...
By: Digital Man to Angus McLeod on Thu Aug 13 2009 02:51 pm

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.

geez what a load.

Caput meum major podice meo.
This message has ended, go in peace...

---
■ Synchronet ■ Three Stooges Gentlemens Club - Las Vegas, Nv

Re: Re: load() search paths..
By: Deuce to Angus McLeod on Thu Aug 13 2009 18:11:00

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.

Perl REs are the de facto standard by which other REs are measured. Not
using csh, I couldn't say if it is equivilent to Perl REs or not. But are
you referring to csh file globbing? That isn't exactly the same as Perl pattern matching.

I guess it depends on the word 'wildcard' which might be the same as the
term 'metacharacter' in a Perl RE, or might *specifically* imply file globbing.


---
■ Synchronet ■ Making sure Jason works OK at The ANJO BBS