[lokisetup] Features for Setup 2.0

[Stéphane Peter]

Some interesting ideas from TTimo. See my comments below.

One thing I'd like to add though regarding portability is that it would
be nice if sometime in the future we are able to build a Win32 version
of setup. Which means that we should have a way to get rid of all the
Unixisms and other assumptions in the current code (things as simple as
/ vs \ for directory separators, or the more general reliance on shell
scripting).

Just something I think we should keep in mind...

Le sam 23/11/2002 à 03:17, Timothee Besset a écrit :
> I love designing new apps. You can have plenty of cool ideas and then
> decide to drop them because it will be too complicated. So here are my
> thoughts:
> 
> - Multiple UIs .. anyone using the SuSE distribution? The yast
> configuration tool has text and qt uis .. pretty much what setup 1.x is
> doing. Very good stuff.

I have seen it in action... Isn't that part of YaST which is proprietary
though ?

> - Is the XML description generic enough to describe the installations? Do
> we need some flow control? (if-then-else?)

That sounds like a good idea - this would also partly remove the need
for some things otherwise achieved through shell scripts.

> - Usage of shell scripts: in 1.x we often drop in shell scripts to perform
> some operations. Are those reliable and portable enough? Would LUA be any
> help?

That would be a problem for non-Unix platforms (i.e. Win32). Although I
suppose we could always ship a small bash.exe to run these with setup
;-). Other scripting languages could be an option, assuming they are
also portable and allow to do the same kind of tricks as in regular
shell scripting: Also a fall-back to the native shell should be allowed,
IMHO.

> - Support 'on-demand' download? i.e. download a small stub package, find
> mirrors to get further elements? I think that's what loki_update does,
> setup and update should be more interdependent?

Like the Ximian installer then ? At first I am thinking this could be
done separately from the core installer package (maybe as an add-on of
some sort).

> - Local caching of the setup UI code? The size of UI-related binaries is
> pretty big in setup packages. Could we have the UI stored in a local cache
> (~/.lokisetup/ui/<API-version-GUID>/)? This would be working with
> 'on-demand' setups. You launch a query program to some XMLized URL, it
> checks if you have the correct UI stuff already and starts downloading?

Setup 1.x already does something remotely similar for the uninstall
program. It is usually copied over to the user's
~/.loki/installed/bin/... hierarchy of directories, and the binary there
is used if no other 'loki_uninstall' binaries are available.

There is the problem that if you have for instance a NFS shared home
directory, you would need to have cached binaries for all the
architectures you are using. Maybe this all thing could be part of the
add-on package I was mentioning above.

IMHO this raises the more important question of binary modularity. This
implies that there would be actual UI backend modules of some sort. So
how would they communicate with the installer core ? Shared .so/.dll's ?
Separate programs communicating with some kind of IPC ? I am kind of
hesitant on this issue given the relatively small sizes of such modules
compared to the core installer (especially if we get modularization
right this time).

> TTimo

-- 
Stephane Peter
Sr. Software Engineer
Codehost, Inc.