Re: [Scrollkeeper-devel] What about the distributions?

[Ali A. <ali...@au...>]

* laszlo kovacs (las...@su...) wrote at 15:58 on 23/10/00:
> > What exactly is the proposal? I don't understand how post-install or
> > partial databases could fix the problem?
> I think the problem was described at the beginning of the proposal. In
> order to install a doc with Scrollkeeper, a script has to be run that
> changes the Scrollkeeper database. If this is done from "make install"
> then the database will be modified when a package is installed with
> "make install" or when the package is turned to another format (like
> RPM) as the conversion process also uses "make install". We dont want
> the later. Eric thinks "make install" should behave indentically when
> run from command line (for installation) or when used to create a
> package in a different format. He also thinks that running Scrollkeeper
> install from a post install script is not an option as then post install
> scripts have to be added to a large number of packages and that would
> upset packagers and post install scripts are slow. He suggests that we
> should use partial databases when we build a package (or install with
> make install, I am not sure, but I dont think it is important). The
> partial database would contain the data of that package's documentation.
> This would be exported to the help browser. So the help browser has to
> deal with partial databases on its own or through a library we supply to
> create an interface that would unify the partial databases for the
> browser.
> 
> > Perhaps we can really do a normal install of the OMF file. When
> > ScrollKeeper access the metadata it would check that the file "really
> > exists" if it does then okay, if it doesn't it gets deleted from the
> > database and "not found" is returned.
> I thought the file would be installed in /tmp at RPM creation so
> Scrollkeeper would think it is installed. Or this is not what you are
> talking about?

Yes, but when the RPM is "done building" it cleans up after itself so the file
would no longer exist under that location.

Perhaps what we need are two directories or something. So you would have:
prefix/var/lib/scrollkeeper/processed
prefix/var/lib/scrollkeeper/unprocessed

An "initial" scrollkeeper-install would put the file in the unprocessed
section, scrollkeeper could then at some designated time, check all files in
the unprocessed section, if they are found on the local drive they are moved
to processed, otherwise they are removed from unprocessed.

But this presents another issue. What about "online docs"? the above
implementation would force people to have docs on the "local" path!!! Instead
of deleting the file, perhaps we should move it into a "not-installed"
directory. That way if the help file is located at
"http://www.doc.com/file.sgml" We could access it from the not-installed
section.

The problem would arise with "syncing" the two directories (what if you have a
"not-installed" doc and then later install it locally)


So perhaps we shouldn't have multiple databases (or directories, or whatever
you want to call it). Perhaps we should always install files...

If a doc is not found/installed locally then ScrollKeeper should handle it.
This sounds a lot like what Eric was saying doesn't it? ;) But he makes it
sound that applications (help browsers) should handle it. Instead, I think
that ScrollKeeper should natively handle it. 

If I ask the ScrollKeeper database for "all installed docs" it would return
that - I /could/ ask for all "not-installed" docs (which would return these
docs + the HTTP ones + FTP ones + etc...)

Generally, when a help browser displays its "Index" (for Nautilus that is the
Help Sidebar) it would only display the "installed" docs...

What do you think of this proposal?

Regards,
Ali