nextloadmodule

[5] a very nice feature that can be implemented is a proprietary file extension to
rename all the litestep modules archives like *.lsz do for theme. the purpose is
not just to differentiate the ls modules from a simple *.zip, but to introduce a
new way to handle module installation:

[5] the need is a small text file at root of the module archive (example: *.lls).
- it must contain the installation step information that the new nlm is going to
manage; some module need special step (not standard�) to work properly, like
xpaintclass (previous version only? :x) asking to be installed next to lsapi.dll.
another example, hotspot, that need his hook *.dll to be near lscore. actually,
the way to handle multiple *.dll installation require that the user read the
documentation (proposed by nlm) or the themer to had "load rainmetter.dll" in his
*netload string. some information given to nlm can avoid newbie from being
discouraged by error messages :).
- it can also provide some settings if needed; for example, lssureshot require the
user (ideally the themer handle this with textedit at the first run) to put
settings in the module.ini. a new way could be that nlm check for existing setting
and if it doesn't find it, write the defaults settings given in the *.lls file.

if all that informations are given, nlm could easily manage the installation of
lscp |see lscp note|.
it can be extended to additional application; i was thinking of a ls approved
application list [3] based on the commonly used / provided one in theme (example:
bsetroot). utilities section exist in shellfront, but is it used? also maybe no
need to provide the application on servers if the *.lls can provide a link for
nlm. all application that is not approved can give an advertisement to the user
when the themes ask for installation; an nlm option can restrict such
installation. [2]if nlm find a dead link it can propose user to go "google" it. |
4|the other side of this system could be that, litestep theme installer could
provide restriction {option} for theme that contain *.exe. when theming, you can
sometimes find useful to provide some small app (example: tinsplash -_-), but is a
matter of orientation to define for litestep: in my mind i try to keep the idea
that ls must do all i need and so i must do all i need via litestep feature (req:
bsetroot.dll :]) and scripting enhancement, so, *.exe feel messy isn't it? the way
to install application could be managed regarding of the ots3 try (i have the doc
& example, but haven't fully study it for now :x).

[4]the "*.lls" file could also contain a small definition string (with a fixed
length rule) and 1/2/3 requirements lines (lscore version / ots limitation /
additional module) and maybe /4 because ls seem to change: lua or python lib (or
wsh)??? in this case a additional link could be added to propose to go download it
at the *nlm time.
the main interest of the definition string could be:
i don't know about php, but because it can provide server side application maybe
it can read a txt file inside a *.zip?? if it can do so, information given in
*.lls could seriously help to feed database and so may inspire other way to
enhance nlm.

[2]here i am offline user; of course i can't contest the coherence of

netloadmodule against ots1 loadmodule, but at the first time i was very
disappointed when trying my first ots2 installation -_-. to continue theming i
have downloaded all the existing modules from shellfront.org. it's nice to see all
what's done, but when i want to update my collection, i often (not all month ;p)
re-download all the module from shellfront � surely i can manage to download with
date filter with my download manager, but it make me think about a nlmsearch.exe.
if database can be build (mainly for themer surely.) like said before, litestep
site can provide interface (what about category definition for *.lls info?) or an
application can be created to manage module; in my mind it look like recent linux
apps installer �

|3|last idea (tricky :x) about the metadata provided, a retro compatibility info;
quick example:
in xlabel 6.32.lsmod \ nlm.lls :
�
retro-compatibility = 6.29 exclude 6.30
�
where 6.29 tell that all version from 6.29 to 6.32 use the same syntax; it may
introduce new settings but not remove settings. exclude 6.30 is optional and self
explain.
all this is if themer / user want to be always up to date (*netloadmodule xmodz-
0.01.00 noupdate?) so nlm manage module revision commenting out theme.rc and
setting new value:
; // netloadmodule original theme revision: xmodz 0.01.00 //

finally, recompiling module archive can take time, but i'm sure that it can be
done progressively (i'm volunteer, of course). date and authors can also be useful
information as src link �
another idea when limiting definition string, is that we may can provide
definition translation (short so quick to translate, can be done at least for new
release); if it overload nlm or database, maybe can we have two metadata file with
each module (*.lls and "*.def") ?

need clearer explanation?

zbm (zemasterbug) - zembug_ta_gmail_tod_com

ps[1]: ifexist "nlmsearch.exe" then gettutorials&documentations(section)...