WardCunningham/Smallest-Federated-Wiki

node server : farm? : local-identity?

almereyda opened this issue · 6 comments

Starting to maintain more than one SFW, I'd like to know if it is intended behaviour for the node/express server (way easier to set up as a service than unicorn/sinatra/...) to:

  • not recognize settings in local-identity, whether in default-data/status nor data/status. i'd love to use the root option, at last
  • not recognize the farm folder, if existing. it would always create a new pages folder in data, also when node is invoked with the -u '[DOMAIN]' parameter.

please close the issue if it appears to be too minor.
thanks in advance; greetings from montpellier.

Too minor? Never. If anything it highlights a known problem that the documentation is not all it might be, and there are differences between the two server implementations that are not documented.

You might want to look at the recent configuration changes over in at WardCunningham/wiki, where most of the current development is happening. There is now support for a configuration file, like local-identity.

The node/express server does not currently automatically enable farm mode if the farm folder exists. Maybe it should? For the time being this has to be done via the configuration.

As far as I remember the -u '[DOMAIN]' parameter is only used as part of the authentication process, at least in the node/express code.

The node/express implementation was written after the ruby/sinatra version with the goal of meeting the same functional tests. The two implementations differ where behavior wasn't tested. Both support farms, but by different means. Our energy (for the moment) is going into the node/npm version @paul90 mentions.

Thanks for your explanations. Keep on rockin'!

Due to the documentation I was aware of the fact, that both versions differ in functionality.
Actually I was not aware of the new repo. Obviously the current development has been moved there, as I have understood by comparing the commit histories of both.

As I would not want to mess with the .coffee files directly, which I might understand a little by now, an explanation or at least a config-rename-template.json would appear helpful.

@paul90 After rethinking the case, I think a dedicated configuration via a config.json, followed by an automatic farm folder structure creation appears more robust. On the other hand flat-file data storage invites to use "intelligent" flat "folder management" as data-specific tasks are already carried out directly in the file system.

[EDIT] We might want to close the issue here and move the discussion over to https://github.com/WardCunningham/wiki/issues .

Thanks. I'll close this now as suggested.

Thanks in return.

Still, any hint anyone could give me on how to write a config.json would be very appreciated.

Well, I could also try to understand the code to find out what it's looking for ...

@almereyda A config gets spit out by the server wrapped in an array when the server starts, looks something like this:

{ _: [],
    autoseed: false,
    test: false,
    help: false,
    h: false,
    '$0': 'node /development/wiki/node_modules/wiki/index.js',
    client: '/development/wiki/node_modules/wiki/node_modules/wiki-client/client',
    db: '/home/user/.wiki/pages',
    status: '/home/user/.wiki/status',
    url: 'http://localhost:3000',
    id: '/home/user/.wiki/status/persona.identity',
    uploadLimit: '5mb',
    neighbors: '',
    database: { type: './page' },
    root: '/development/wiki/node_modules/wiki/node_modules/wiki-server',
    packageDir: '/development/wiki/node_modules/wiki/node_modules',
    data: '/home/user/.wiki',
    debug: true 
}

Readme says to place it in the root directory, but root is not the root in the config (wiki-server), it's the same directory that holds the base wiki directory. In the above example, /development/node_modules.