[Sputnik-list] New commit of Sputnik with Subversion

[Yuri Takhteyev]

First, after tweaking the sequence of commands a bit, I did manage to
build luasvn from scratch and to run it.  See
http://www.freewisdom.org/projects/sputnik/Building_LuaSVN

The bad news, however, is that when a module is built this way,
LD_LIBRARY_PATH must be set not only when it's being built but also
later whenever it is being used.  I imagine that xavante runs with
whatever environment variables are set at the command line before it
is started, but is typically configured to run with whatever variables
it wants to run.  Maybe there is a way to set LD_LIBRARY_PATH from Lua
before requiring luasvn - I am not sure.  Though, I seem to see that
people out there on the Internets are saying that LD_LIBRARY_PATH is a
dirty hack anyway.  (E.g.,
http://linuxmafia.com/faq/Admin/ld-lib-path.html)  So, maybe instead
of figuring out how to set environment variables in Kepler we should
look into what we should do to not have to set them.

> Once you have suggested the "get_object_history" should return two things for each file: the
> ID of the file and the last time it was modified.

I still think so to some extent.  Conceptually, there are two separate
things: an revision ID, which could be anything, an, and a timestamp,
that needs to be in a particular format.  My implementation for
wikifilestorage used timestamps as IDs and mixed them everywhere, but
this is a mistake to be fixed, rather than emulated in all future
storage modules.

What I am not 100% sure about is whether get_object_history should
really be returning timestamps at all.  Part of me thinks it would be
cleaner if it just returned IDs.  After all, if we return timestamps,
why not also return username and other metadata.  So, it starts
smacking of a wikifilestorage-specific optimization.

> I tried to do this change once, it seemed to work. I don't know if you are still thinking this way, or
> if you think is better to use the config_table (I did not think about this yet).

The config table is a completely different story.  I am suggesting
that one would connect to a storage module using
`module_name.open(config)` where config is the table we get after
processing the config file.  This way, the module can pick whatever it
wants from the config file to initialize itself.  E.g. wikifilestorage
could use config.WIKI_DATA_DIR, sqlite storage would use
config.SQLITE_FILE_NAME, and storage systems based on other databases
could use DB_HOST_NAME, DB_USER_NAME, DB_PASSWORD, etc.  The point is
that Sputnik wouldn't need to know whether a storage module needs 1
config variable, 2 or 75.

Alternatively, we could use a single table-valued config variable for
that, which would be cleaner but probably more confusing to new users:

STORAGE = {
   module = "wikifilestorage",
   dir = "/home/yuri/sputnik/data/"
}

or

STORAGE = {
    module = "wikidbstorage",
    db = "mysql",
    host_name = "localhost",
    user_name = "test",
    password="apples"
}

  - yuri

-- 
Yuri Takhteyev
UC Berkeley School of Information
http://www.freewisdom.org/