TiddlyWebWiki: bootstrapping twanager instance
FND
bootstrapping problem because a tiddlywebconfig.py with twanager_plugins
is needed to add the instance command.
Solutions that have been suggested so far include creating a script
independent of twanager and using an environment variable or config file.
None of those seem very appealing.
However, what if the core's twanager could be passed a parameter
indicating which configuration or plugin to load?
That way TiddlyWebWiki's twanager commands could be invoked like so:
twanager --plugin tiddlywebwiki.plugin instance foo
-- F.
* http://groups.google.com/group/tiddlyweb/t/a8532a32d181e937
tony
On Jul 17, 5:32 am, FND <F...@gmx.net> wrote:
> However, what if the core's twanager could be passed a parameter
> indicating which configuration or plugin to load?
> That way TiddlyWebWiki's twanager commands could be invoked like so:
> twanager --plugin tiddlywebwiki.plugin instance foo
i assume tiddlyconfig.py would still be edited manually as well or
will automagic prevail?!
To convert a text store to sql, something like...?
$twanager --plugin tiddlywebwiki.update instance foo
$twanager --plugin tiddlywebwiki.migrate instance foo
$twanager --plugin tiddlywebwiki.sql instance foo
Best,
tony
FND
> will automagic prevail?!
Well, this parameter would only really be useful if there is no
tiddlywebconfig.py to begin with. If you're already in an instance,
there should be no need to invoke twanager_plugins via the command line.
> To convert a text store to sql, something like...?
> $twanager --plugin tiddlywebwiki.update instance foo
> $twanager --plugin tiddlywebwiki.migrate instance foo
> $twanager --plugin tiddlywebwiki.sql instance foo
That's not quite what I had in mind.
Presumably, store migration always happens within an instance, so you
can use tiddlywebconfig.py to invoke the plugin.
(One could imagine the migrate plugin adding a twanager command that
accepts server_store and target_store parameters, but that's unrelated.)
Also, you use tiddlywebwiki.{update,migrate,sql} there, which makes me
think I need to clarify my earlier example:
$ twanager --plugin tiddlywebwiki.plugin instance foo
That would load the "plugin" module from the "tiddlywebwiki" package*
(which adds various twanager commands) - just as if there was a
tiddlywebconfig.py with the following entry:
'twanager_plugins': ['tiddlywebwiki.plugin']
-- F.
*
http://github.com/tiddlyweb/tiddlywebwiki/blob/master/tiddlywebwiki/plugin.py
Chris Dent
On Jul 17, 2009, at 1:32 PM, FND wrote:
> Solutions that have been suggested so far include creating a script
> independent of twanager and using an environment variable or config
> file.
> None of those seem very appealing.
Is the independent script unappealing because it leads to a
proliferation of scripts? That's a fine concern but I think it needs
to be balanced against the task you are asking the user to learn and
perform. If someone presents me with instructions like:
* easy_install -U tiddlywebwiki
* twanager --add_{config,plugin} tiddlywebwiki.plugin instance mydir
I might think: "Couldn't they just give me a command for that?" and
then if I were a supercilious sort of fellow I might make an alias or
script in my local environment, mostly because I can't tab complete
greater than 50% of the above.
I do think the functionality to force twanager to add some config is
probably useful, but I don't think it solves the problem under
question (and has other issues, below).
> However, what if the core's twanager could be passed a parameter
> indicating which configuration or plugin to load?
> That way TiddlyWebWiki's twanager commands could be invoked like so:
> twanager --plugin tiddlywebwiki.plugin instance foo
In addition to the issues above, one concern I have with this is that
if we're going to add command line flags to twanager then it would be
useful for twanager_plugins to be able to add flags too, because
that's fair, and then all of a sudden this little script that was just
kind of there to make the game go gets all out of hand and powerful
and stuff.
Which is not such a bad thing, but because it involves a typing UI, is
not something I think should be taken lightly. Maybe it is just a sign
of our little baby growing up.
Internal to the system, it seems like make_command could be extended
to take a **kwargs or plain dict containing command line flags and
defaults to add to the default set of flags (such as
add_config,add_plugin,plugin whatever it is called).
FND
> proliferation of scripts?
Yes, pretty much.
> I might think: "Couldn't they just give me a command for that?" and
> then if I were a supercilious sort of fellow I might make an alias or
> script in my local environment
That's exactly what you should be doing IMO - if you frequently use the
instance command.
> I do think the functionality to force twanager to add some config is
> probably useful, but I don't think it solves the problem under
> question
Why not? The problem is getting access to the instance command without
the need for a tiddlywebconfig.py in CWD, which this solves by
referencing a module on sys.path.
> if we're going to add command line flags to twanager then it would be
> useful for twanager_plugins to be able to add flags too
YAGNI?
Seems like a bit of an orthogonal issue which we can worry about once
there's a specific use case.
> Internal to the system, it seems like make_command could be extended
> to take a **kwargs or plain dict containing command line flags and
> defaults to add to the default set of flags
That sounds like it wouldn't be hard to implement.
-- F.
chris...@gmail.com
> > I might think: "Couldn't they just give me a command for that?" and
> > then if I were a supercilious sort of fellow I might make an alias or
> > script in my local environment
>
> That's exactly what you should be doing IMO - if you frequently use the
> instance command.
that work we are willing to do and think other people should do, isn't
necessarily going to happen.
> > I do think the functionality to force twanager to add some config is
> > probably useful, but I don't think it solves the problem under
> > question
>
> Why not? The problem is getting access to the instance command without
> the need for a tiddlywebconfig.py in CWD, which this solves by
> referencing a module on sys.path.
to use tiddlywebwiki can get underway easily.
If it is, in fact, the latter, then I think a shorter dance may be
warranted.
Jeremy Ruston
people who are using it. I think that the biggest, easiest to reach
set of people are those who find TiddlyWiki appealing, but want the
multiuser functionality offered by TiddlyWeb. I'm happy enough for
TiddlyWeb to spit out TiddlyWebWiki as a separate subcomponent,
because it makes sense in engineering terms. And it has no impact on
Osmosoft's ability to use the thing. But in terms of *product*, it's
TiddlyWebWiki that's best way to drive adoption.
We can see from the activity on
http://search.twitter.com/search?q=tiddlywiki that people love
TiddlyWiki, often at first sight. We need to leverage that love to
drive adoption of TiddlyWeb.
So, to my mind, for Osmosoft, there are two desirable goals:
- to create a distribution of TiddlyWebWiki that's simple enough for
Windows, OS X and Linux users to get up and running. "Simple enough"
in practice probably means a GUI wrapper around an installer
- to create a TiddlyWebWikiSpot product that adds the bits and bobs
necessary to support a self-service TiddlySpot-type offering
Perhaps implicit in this approach is Chris's idea that TiddlyWeb is a
*component* of the overall product(s), and not the entirety of them.
Cheers
Jeremy
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Chris Dent
Packaging as in both packaging code for distribution and packaging as
in getting our brains around it.
On Jul 21, 2009, at 12:19 PM, Jeremy Ruston wrote:
> So, to my mind, for Osmosoft, there are two desirable goals:
> - to create a distribution of TiddlyWebWiki that's simple enough for
> Windows, OS X and Linux users to get up and running. "Simple enough"
> in practice probably means a GUI wrapper around an installer
Python has py2exe and py2app that make Windows executables and Mac
applications (respectively) from a collection of python modules and
assorted other bits of code. They are fiddly but I'm told get the job
done once you get past the fiddling stage. On the Linux side, making
rpms and debs is not that hard and there are support tools for making
it happen.
In fact distutils + Setuptools (the project from whence easy_instal
hails) has these commands:
bdist_rpm create an RPM distribution
bdist_wininst create an executable installer for MS Windows
py2app create a Mac OS X application or plugin from
Python scripts
bdist_mpkg create a Mac OS X mpkg distribution for
Installer.app
But each takes some poking tweaking, etc to get going. At this stage
it is simply a matter of doing it, iterating through the failures,
until it is working and repeatable.
> - to create a TiddlyWebWikiSpot product that adds the bits and bobs
> necessary to support a self-service TiddlySpot-type offering
Have made a few aborted attempts at this over time, but have stalled
out needing bits and bots on the client side. That side has renewed
energy of late so I think we'll see some fun soon.
> Perhaps implicit in this approach is Chris's idea that TiddlyWeb is a
> *component* of the overall product(s), and not the entirety of them.
There's three things TiddlyWeb is as seen in the wild so far:
* Headless REST sever for storing stuff in a tiddly-way (i.e. as
granular, permanently addressable bits of stuff). (Scrumptious, Cork,
etc.)
* The "backbone" for what is now called TiddlyWebWiki: A multi-user
collaborative platform for doing wiki-stuff in a tiddly-way. (http://tiddlyweb.peermore.com/
and others)
* A(n unintentional) framework for hosting web applications. ILGA, the
recent wiki-data work.
TiddlyWeb is well suited to the first two, I'm not so sure about the
third. Jury is out. The primary distinguishing feature between items 1
and 3 is who or what has control of the presentation layer and to what
degree. If the presentation layer is 100% in the hands of TiddlyWeb,
then it is three.
My insight that led to TiddlyWebwas that TiddlyWeb and TiddlyWebWiki,
by being in the same pot, were mutually limiting each other and that
with a little separation they'd both get a kick. This has proven to be
very true. As you say, a sort of engineering solution: tease the
problem into manageable pieces.
How things are physically packaged doesn't need to have any impact on
how the different parts are packaged from a branding standpoint. I
agree that TiddlyWebWiki and a TiddlyWebWikiSpot are key.
Jeremy Ruston
> applications (respectively) from a collection of python modules and
> assorted other bits of code. They are fiddly but I'm told get the job
> done once you get past the fiddling stage. On the Linux side, making
> rpms and debs is not that hard and there are support tools for making
> it happen.
Aha, good stuff. Perhaps ticket it as a job that needs doing?
> There's three things TiddlyWeb is as seen in the wild so far:
>
> * Headless REST sever for storing stuff in a tiddly-way (i.e. as
> granular, permanently addressable bits of stuff). (Scrumptious, Cork,
> etc.)
>
> * The "backbone" for what is now called TiddlyWebWiki: A multi-user
> collaborative platform for doing wiki-stuff in a tiddly-way. (http://tiddlyweb.peermore.com/
> and others)
>
> * A(n unintentional) framework for hosting web applications. ILGA, the
> recent wiki-data work.
I think of ILGA and WikiData as being in the first category; the
reason we've based both of them on TiddlyWeb rather than Django or
something is to get TiddlyWeb's effortless multiformat publishing
stuff. I'm conscious that the only route to that data is currently web
pages hosted by TiddlyWeb, but I think of that as an implementation
detail that will look different as we (and others) build other things
that connect to the ILGA and WikiData data stores.
Cheers
Jerm
Chris Dent
On Jul 21, 2009, at 3:22 PM, Jeremy Ruston wrote:
>
>> Python has py2exe and py2app that make Windows executables and Mac
>> applications (respectively) from a collection of python modules and
>> assorted other bits of code. They are fiddly but I'm told get the job
>> done once you get past the fiddling stage. On the Linux side, making
>> rpms and debs is not that hard and there are support tools for making
>> it happen.
>
> Aha, good stuff. Perhaps ticket it as a job that needs doing?
http://trac.tiddlywiki.org/ticket/798
Opened nine months ago. Hasn't happened yet because ticket handling
has basically proceed by two forces:
* popular clamoring (where popular means on the various mailing lists
or in the ticket itself)
* If no popular clamoring, the severity of the bug when I or FND
experience it
> I think of ILGA and WikiData as being in the first category; the
> reason we've based both of them on TiddlyWeb rather than Django or
> something is to get TiddlyWeb's effortless multiformat publishing
> stuff. I'm conscious that the only route to that data is currently web
> pages hosted by TiddlyWeb, but I think of that as an implementation
> detail that will look different as we (and others) build other things
> that connect to the ILGA and WikiData data stores.
Well that's what I've been hoping too, but perhaps for the time it is
accurate to say that ILGA and WikiData are in 3 (framework) now with
plans to migrate in a 1ward direction?
FND
>
> Is that the problem, or is the problem making it so someone who wants
> to use tiddlywebwiki can get underway easily.
I think it's purely the former - i.e. the engineering part.
The latter should probably be addressed from a different angle (see the
parallel discussion on packaging).
-- F.
tony
> http://trac.tiddlywiki.org/ticket/798
>
> Opened nine months ago. Hasn't happened yet because ticket handling
> has basically proceed by two forces:
>
> * popular clamoring (where popular means on the various mailing lists
> or in the ticket itself)
to 1.0, I agree and wish more folks try/use/adopt it through a binary
like http://luminotes.com/, good consistent install instructions/
process, or great use cases like Jon's rss feed sync to generate
interest and help lower entry barriers hopefully expanding the user
base.
Additionally, one of the great appeals of Tiddlywiki and Tiddlyweb is
all the fiddling and tinkering users engage in. It's a great learning
experience and I hope whatever canonical form(s) Tiddlyweb/webwiki
develop in the future, such design consideration is never lost.
I think there is a market of folks eager to learn 'how' after/during
the 'what can this do' phase.
Thanks for the all the great work, it's a fun journey.
Best,
tony
FND
This has now been implemented:
http://github.com/tiddlyweb/tiddlyweb/commit/2c3701d1450504da71d7fe6477a1cf7e9af3352a
http://github.com/tiddlyweb/tiddlywebwiki/commit/adc9434e5f2b553e8e0d8578a014518666470d5d
So from the next TiddlyWeb release on, you should be able to do the
following:
$ twanager --load tiddlywebwiki.plugin instance foo
I will update the TiddlyWebWiki README accordingly.
-- F.
FND
Sorry, that should be tiddlywebwiki.config there...
Either way, the README has it right. The releases of both TiddlyWeb and
TiddlyWebWiki have been updated to include this now.
-- F.
tony
> > $ twanager --load tiddlywebwiki.plugin instance foo
>
> Sorry, that should be tiddlywebwiki.config there...
It works great on Windows/cygwin with
$ twanager --load tiddlywebwiki.config instance foo
But I could not get imwiki going [1]:
$ twanager imwiki ~/My\ Documents/tw/wiki.html wikibag
results: NameError: global name 'config' is not defined
Any suggestions?
Best,
tony
[1] Traceback (most recent call last):
File "/usr/bin/twanager", line 5, in <module>
pkg_resources.run_script('tiddlyweb==0.9.55', 'twanager')
File "/usr/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/
pkg_resources.py", line 448, in run_script
File "/usr/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/
pkg_resources.py", line 1173, in run_script
File "/usr/bin/twanager", line 14, in <module>
File "build/bdist.cygwin-1.5.25-i686/egg/tiddlyweb/manage.py", line
246, in handle
File "build/bdist.cygwin-1.5.25-i686/egg/tiddlywebwiki/twanager.py",
line 21, in imwiki
File "build/bdist.cygwin-1.5.25-i686/egg/tiddlywebwiki/twanager.py",
line 67, in _store
NameError: global name 'config' is not defined
FND
> results: NameError: global name 'config' is not defined
Indeed, there seems to be something weird going on in
tiddlywebwiki.plugin; even after creating a TWW instance, running
twanager out of the instance dir (with tiddlywebconfig.py containing
twanager_plugins) won't actually show the additional commands.
I don't see any obvious errors right now - will have to investigate.
For now, you can work around this by invoking tiddlywebwiki.config directly:
$ twanager --load tiddlywebwiki.config imwiki foo.html bar
-- F.
Chris Dent
On Jul 30, 2009, at 12:50 PM, FND wrote:
> Indeed, there seems to be something weird going on in
> tiddlywebwiki.plugin; even after creating a TWW instance, running
> twanager out of the instance dir (with tiddlywebconfig.py containing
> twanager_plugins) won't actually show the additional commands.
>
> I don't see any obvious errors right now - will have to investigate.
This is basically my fault. I made a change in tiddlywebwiki/plugin.py
that removes the manual initialization of the fromsvn, instancer and
twanager modules. I then tested it in the new way of doing things but
not the old, failing to notice that there was not a bootstrapping
problem (twanager can't know about the new plugins from the config
because we are already past the point where tiddlyweb/manager.py has
started processing twanager_plugins from the config).
A fix will be released soon. The simple solution of just returning the
missing inits, though it returns the commands, doesn't allow the
commands to be listed when you run twanager by itself.
Turns out that second half is a problem in the tiddlyweb core.
I've committed fixes for both problems and there will be releases soon
(probably tomorrow).
tony
> (probably tomorrow).
load tiddlywebwiki.config instance foo
and some fix enabled TiddlyWebwiki to save as user: mobile on iPhone
OS. Su root no longer needed further easing starting up
MobileTiddlyWiki!
Only hicccup I see to a seamless bootstrapping experience is some
offline documentation in twanager like $man twanager as user may
forget command syntax. At first I started a tiddlyweb to record
testing experiences, tips and failures then I'd post to group or
comment at tiddlyweb.com only to forget some config or steps and have
to search these places again. I really miss the plain text /docs/
COOKBOOK from the early distro days; it was offline, easy to use-
great to teach the user on how to get TiddlyWeb up and running.
Once the road to 1.0 is met and is less of a moving target, I think
$twanager help is a good space for this
and I would be happy to pitch in if needed.
Best,
tony
Chris Dent
On Aug 8, 2009, at 4:16 PM, tony wrote:
> Only hicccup I see to a seamless bootstrapping experience is some
> offline documentation in twanager like $man twanager as user may
> forget command syntax. At first I started a tiddlyweb to record
> testing experiences, tips and failures then I'd post to group or
> comment at tiddlyweb.com only to forget some config or steps and have
> to search these places again. I really miss the plain text /docs/
> COOKBOOK from the early distro days; it was offline, easy to use-
> great to teach the user on how to get TiddlyWeb up and running.
The removal of the COOKBOOK happened because the instructions for how
to make tiddlyweb go were changing faster than the COOKBOOK and it
seemed better to have no info than incorrect information.
You do know that you can run twanager without any arguments and it
will list all the available commands and give a brief synopsis of the
how the arguments are to be arranged?
> Once the road to 1.0 is met and is less of a moving target, I think
> $twanager help is a good space for this
> and I would be happy to pitch in if needed.
Excellent, that would be very helpful.
I think one useful option might be to extend the make_command
decorator so that it can provide both short one liner docs and longer
docs such that
twanager help <command>
would produce the longer doc info.
But yes, we need the target to stop moving around before really
nailing this issue. I think we're getting close.
tony
> I think one useful option might be to extend the make_command
> decorator so that it can provide both short one liner docs and longer
> docs such that
>
> twanager help <command>
>
> would produce the longer doc info.
I really enjoyed your clear friendly hand held way COOKBOOK was
crafted :-)
> But yes, we need the target to stop moving around before really
> nailing this issue. I think we're getting close.
platforms; Firefox, Chrome, IE, Safari, MobileSafari!
tony
> > making it so someone who wants to use tiddlywebwiki can get underway easily
I tried to upgrade to Tiddlywebwiki 0.8 via easy_install but got a
sandbox error on WinXP/cygwin [1]
Luckily, I was able to install Tiddlywebwiki from the tarball.[2]
I saved the traceback and can forward if needed.
Please let me know if I'm being a bad Tiddlyweb citizen by reporting
here instead of http://trac.tiddlywiki.org; I figure things are still
in progress.
Thank you!
Best,
tony
[1] The following error occurred while trying to extract file(s) to
the Python egg
cache:
SandboxViolation: mkdir('/cygdrive/c/Documents and Settings/
me/.python-eggs/tiddlyweb-0.9.62-py2.5.egg-tmp', 511)
{}
The package setup script has attempted to modify files on your system
that are not within the EasyInstall build area, and has been aborted.
This package cannot be safely installed by EasyInstall, and may not
support alternate installation locations even if you run its setup
script by hand. Please inform the package's author and the
EasyInstall
maintainers to find out if a fix or workaround is available.
[2] got the latest tarball from http://tiddlyweb.peermore.com/dist/
$ tar -xzvf tiddlywebwiki-0.8.tar.gz
$ cd tiddlywebwiki-0.8
$ python setup.py install
$ twanager --load tiddlywebwiki.config instance <my instance>
$ twanager info
This is TiddlyWeb version 0.9.62.
The current store is: text.
System Plugins: tiddlywebwiki (0.8)
tony
> I tried to upgrade to Tiddlywebwiki 0.8 via easy_install but got a
> sandbox error on WinXP/cygwin [1]
empty and $twanager update didn't help.
So basically, I can't get Tiddlyweb core 0.9.62 with Tiddlywebwiki 0.8
working :-(.
No problem, though, I'll downgrade back.
I also got the same install error when trying easy_install on Mac
Leopard if that helps any [1]
Best,
tony
[1] SandboxViolation: mkdir('/Users/tony/.python-eggs/tiddlyweb-0.9.62-
py2.5.egg-tmp', 511) {}
Chris Dent
On Sep 1, 2009, at 10:08 PM, tony wrote:
> [1] The following error occurred while trying to extract file(s) to
> the Python egg
> cache:
>
> SandboxViolation: mkdir('/cygdrive/c/Documents and Settings/
> me/.python-eggs/tiddlyweb-0.9.62-py2.5.egg-tmp', 511)
> {}
This was happening because of what amounted to a dependency cycle
between tiddlywebwiki and tiddlyweb.
The plugin handling for tiddlywebwiki was moved into the __init__
file, which was also being used to harvest the tiddlywebwiki version
number by setup.py. When that harvesting was happening, various
tiddlyweb files were being imported, causing some pkg_resource
handling to be started, which mean an egg needed to unpacked, which
setup.py didn't like, etc etc.
So I moved those imports so they don't have happen when the file is
imported, only when init() is run.
In the process I also have to fix some tests.
I've created a tiddlywebwiki 0.9, if you could try to install that and
let me know if it is working, that would be great.
Thanks.
tony
> I've created a tiddlywebwiki 0.9, if you could try to install that and
> let me know if it is working, that would be great.
works that is the good news,
but for some reason saving is not working well.
I'm getting selective saving with recipes from imported bags when i
look at the log $ grep 'PUT' < tiddlyweb.log
Save changes button doesn't work 'sometimes'!?
and for some reason I'm not able to kill CherryPy with a ctrl-c at
the command line.
it is as if CherryPy is either taking a long time to save, saving in
chunks or hung up on a process. CherryPy won't die! :-)
When I close out the terminal and try again, I'm able to save fine to
default and recipes with imported bags, the save changes button
presents the dialog with saved tiddlers making it difficult to pin
down what the issue is.
Everytime I restart CherryPy and save to a recipe from an imported
bag, a new set of tiddlers are saved or so I think with the dialog.
I did notice something interesting though, the new default for
twanager server host is 0.0.0.0 but when i go to the browser as
0.0.0.0 that doesn't work, but localhost does. Given that, I've been
specifically testing with 127.0.0.1:8080, WinXP, no policy changes.
Okay I looked at the log again and saw only PUTs by GUEST; I tried
adduser and finally got a error [1]
I'll give it a go with the mac later.
Hopefully, more folks will post their successes.
Best,
tony
[1] $ twanager server 127.0.0.1 8080
Starting CherryPy at 127.0.0.1:8080
File "build/bdist.cygwin-1.5.25-i686/egg/tiddlyweb/store.py", line
108, in put
return func(thing)
File "build/bdist.cygwin-1.5.25-i686/egg/tiddlyweb/stores/text.py",
line 213, in tiddler_put
raise StoreLockError(exc)
StoreLockError: write lock for store/bags/kb/tiddlers/EditTemplate
taken by 1868
Chris Dent
On Sep 2, 2009, at 7:10 PM, tony wrote:
> I did notice something interesting though, the new default for
> twanager server host is 0.0.0.0 but when i go to the browser as
> 0.0.0.0 that doesn't work, but localhost does. Given that, I've been
> specifically testing with 127.0.0.1:8080, WinXP, no policy changes
In order to get saving on windows working, you need to explicitly set
the server_host values in tiddlywebconfig.py to http, <some ip>, and
<some port> and then start the server with twanager server.
(no additional args for that).
In your case you'll want <some ip> to be 127.0.0.1 instead of the
default 0.0.0.0, because Windows doesn't seem to like 0.0.0.0.
If you leave server_host as the defaults, but start the server with
'twanager server 127.0.0.1 8080', you'll have an interesting conflict:
You'll be able to get to the TiddlyWeb served pages at http://127.0.0.1:8080/
but the TiddlyWiki that is created will have the server.host
attribute on the tiddlers set to http://0.0.0.0:8080 and the browser
will hang trying to save.
Starting the server with explicit IP and PORT on the command line
doesn't not override the server_host settings for exactly that
situation where you want server.host on the tiddlers to be different
from the IP number that the server is listening on. This will often be
the case when your server is behind some kind of NAT or Port
forwarding device.
tony
> In order to get saving on windows working, you need to explicitly set
> the server_host values in tiddlywebconfig.py to http, <some ip>, and
> <some port> and then start the server with twanager server.
for this: http://tiddlyweb.peermore.com/wiki/recipes/docs/tiddlers/server_host
I was able to save properly in windows with server_host 127.0.0.1 but
ran into some trouble with changing users from GUEST to myself. I
think messed up with twanager addrole params which gave the
StoreLockError: write lock
When i get back to diurnal Windowing, i'll try again and post to the
user/role thread :-)
As for Mac, it just works :-)
I went ahead and did 0.0.0.0 for server_host just to make sure, plus
the config saves having to type. I also upgraded to core 0.9.63 and
set no user or roles so maybe that is why I have no troubles.
> Starting the server with explicit IP and PORT on the command line
> doesn't not override the server_host settings
This is good to understand, so when the twanager help says...
server: Start the server using config settings. Provide <host name
or IP number> <port> to override.
does that mean
twanager server <host> <port> overrides tiddlyconfig server_host
{<host> <port>}?
I tried it on my Mac with success on PUT with twanager server
127.0.0.1:10000 overridding my tiddlyconfig of 0.0.0.0:8080
Luckily I'm looking at tiddlywebwiki solo so I guess my server_host
will always be the same so I'll be fine with explicit config in
tiddlywebconfig.py and $twanager server
Best,
tony