[SM-Discuss] alternative grimoire layout

Andrew afrayedknot at thefrayedknot.armory.com
Tue Apr 5 19:05:34 EDT 2005


Im going to summarize as best I can some discussion that occured on irc...
Apologies in advance if I misrepresent something.

Theres three problems to solve:

organizing spells in a way useful to
1) developers (who is maintaining what)
2) spell inheritence
3) users

So, we make a distinction between the 'in-repository' organization
and the 'on-disk' organization.

The in-repository layout can be based on whatever is convenient for devs,
in other words, organized by who maintains what spells.

The on-disk layout is designed to best accomidate spell inheritence and
code sharing between similar spells. This layout is whats in the
tarballs we distribute and what lands on the users machine in
/var/lib/sorcery/codex/

The in-repository layout can be thought of as a 'source tree' whereas the
'on-disk' layout is the build tree. We will thus have scripts to 'build'
the grimoire, we technically already have this (its called tar), we'd
just make it more complicated such that it would re-organize the spells
then make the tarball. There'd be metadata somewhere to specify where
spells go. There could be a facility to link the source tree layout to
the build tree layout so you could cast spells you're developing without
having to 'rebuild' the grimoire build tree.

So, users never see the source tree, they see the build tree, which is
organized based on spell inheritence and code sharing. To solve problem
3 we implement the symlink forest idea based on keywords. This is a
distinct work area from the relationship between 1 and 2. The actual
mechanics of 3 havent been fully hashed out yet though, but the gist
of it is that the symlink trees can be generated by the users choice
of categories (this is all very abstract).

We can solve problem 1 and maintain our current grimoire layout without
users ever knowing. I suggest we work on this first. At that point we
work on 2 and move spells around based on where they could best take
advantage of code inheritence.

Independently from that we should come up with a way to map keywords and
categories together so we can best generate a convenient symlink forest
for users to browse with file commands.

In summary, theres two distinct areas of work
the
in-repository -> on-disk translator
and the
on-disk -> user convenient layout translator

-Andrew

-- 
__________________________________________________________________________
|Andrew D. Stitt                           | astitt at sourcemage.org    |
|irc: afrayedknot                          | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus    | acedit at armory.com        |
|Sorcery Team Lead                         | ftp://t.armory.com/         |
--------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050405/1999485b/attachment.bin 


More information about the SM-Discuss mailing list