wish list: multi-user access / one click install / best of both worlds / TW server API proposal
SimonHF
this 'Dev' NG exists...)
It seems to me that the main reason why TW is so well loved is because
all scripts & data are included within one convenient html file.
However, it is such a pity that there is no standard solution for
multi-user access. And, more importantly, no up-and-coming 'one click
install' solution for multi-user access. By 'one click install' then I
mean a single 'exe' that one can download onto the desktop and start
and which then automatically starts the browser showing TW (the URL can
then simply be passed around to colleagues in an office environment, or
passed around to friends using, e.g., DynDNS for broadband/DSL home
users) -- in constrast to virtually all TW server-based derivatives
which rely on multiple third party tools being installed (e.g. Apache,
MySQL, Ruby, PHP, Perl, Java, etc). Ideally it would be possible for
such an executable to not only serve individual Tiddlers (for usual
server-based interactive use) but also to serve (or import) large(r)
sets of Tiddlers which are effectively 'exported' or 'imported' for
off-line use. Such an exported set of Tiddlers would effectively be
very similar to the single TW html file that we all know and love
today.
How to achieve this? TW could detect automatically whether it has been
started from a file or from the special TW server. In file mode then TW
would behave like it does today, with the exception of extra
functionality to synchronize its Tiddlers with a particular TW server.
In server mode then TW would fetch all Tiddlers dynamically via AJAX /
Web2.0 asynchronous technology, and there would be notifications like
'user x is editing this tiddler since ...' etc. The thing is that there
would still be just one set of TW JavaScript which behaves differently
depending upon how the TW is started.
Further, I imagine a generic TW server API so that not only can we come
up with the 'one click install' TW but also other developers can create
TW server solutions using the standard TW server API but using their
favorite third party tools, e.g. Apache, MySQL, or whatever.
Comments?
Bob McElrath
> How to achieve this? TW could detect automatically whether it has been
> started from a file or from the special TW server. In file mode then TW
> would behave like it does today, with the exception of extra
> functionality to synchronize its Tiddlers with a particular TW server.
> In server mode then TW would fetch all Tiddlers dynamically via AJAX /
> Web2.0 asynchronous technology, and there would be notifications like
> 'user x is editing this tiddler since ...' etc. The thing is that there
> would still be just one set of TW JavaScript which behaves differently
> depending upon how the TW is started.
I have thought about all of the above, and most of it is in my TODO file
for ZiddlyWiki.
> Further, I imagine a generic TW server API so that not only can we come
> up with the 'one click install' TW but also other developers can create
> TW server solutions using the standard TW server API but using their
> favorite third party tools, e.g. Apache, MySQL, or whatever.
I've thought about this as well. I've broken out the ZiddlyWiki
javascript code so that it is a true plugin. One can then just tell it
where the server is, if the server conforms to a particular API. Some
of the existing ZW communication involves some obscure flags in certain
places of the XMLHttpRequest. I would rather switch to e.g. passing
div's back and forth.
Of course this plugin only makes sense if the server *exists*. So I
don't think people should go installing it in their TW. Instead, the
server should automatically install it if appropriate. And, the same
plugin could be used with several server-sides.
If you'd like to help with this effort, please see:
http://ziddlywiki.com/#ZiddlyContributions
and my test site with the ZiddlyWikiPlugin:
http://ziddlywiki.com/test2.1#ZiddlyWikiPlugin
(I haven't checked that into svn yet -- needs more testing)
--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]
A people that values its privileges above its principles soon loses both.
- Dwight Eisenhower
SimonHF
> SimonHF [sim...@gmail.com] wrote:
> > How to achieve this? TW could detect automatically whether it has been
> > started from a file or from the special TW server. In file mode then TW
> > would behave like it does today, with the exception of extra
> > functionality to synchronize its Tiddlers with a particular TW server.
> > In server mode then TW would fetch all Tiddlers dynamically via AJAX /
> > Web2.0 asynchronous technology, and there would be notifications like
> > 'user x is editing this tiddler since ...' etc. The thing is that there
> > would still be just one set of TW JavaScript which behaves differently
> > depending upon how the TW is started.
>
> I have thought about all of the above, and most of it is in my TODO file
> for ZiddlyWiki.
:-)
> > Further, I imagine a generic TW server API so that not only can we come
> > up with the 'one click install' TW but also other developers can create
> > TW server solutions using the standard TW server API but using their
> > favorite third party tools, e.g. Apache, MySQL, or whatever.
>
> I've thought about this as well. I've broken out the ZiddlyWiki
> javascript code so that it is a true plugin. One can then just tell it
> where the server is, if the server conforms to a particular API. Some
If I understand correctly the ZiddlyWiki is currently a sort of
two-and-a-half-click-install solution... (1) download Zope, (2)
download ZiddlyWiki server-side scripts, (2.5) quickly configure & run.
I'd be interested in doing an alternative server-side,
one-click-install exe which handles the API (using your idea then
initially a TW html side would be served containing the ZW plugin). I
had a quick look at ziddlywiki.com but couldn't find an API description
page...
I'm also interested in building-in an auto-javascript-instrumentation
feature into such a server so as to more easily debug the TW/ZW plug-in
at run-time. Such output from instrumented code could also be used as
the basis for a test suite too.
> of the existing ZW communication involves some obscure flags in certain
> places of the XMLHttpRequest. I would rather switch to e.g. passing
> div's back and forth.
>
> Of course this plugin only makes sense if the server *exists*. So I
> don't think people should go installing it in their TW. Instead, the
> server should automatically install it if appropriate. And, the same
> plugin could be used with several server-sides.
>
> If you'd like to help with this effort, please see:
> http://ziddlywiki.com/#ZiddlyContributions
> and my test site with the ZiddlyWikiPlugin:
> http://ziddlywiki.com/test2.1#ZiddlyWikiPlugin
Unfortunately here I got the following message using Firefox: 'Error: A
script from "http://ziddlywiki.com" was denied UniversalBrowserRead
privileges.'
Greetings from Berlin,
Simon
Bob McElrath
> If I understand correctly the ZiddlyWiki is currently a sort of
> two-and-a-half-click-install solution... (1) download Zope, (2)
> download ZiddlyWiki server-side scripts, (2.5) quickly configure & run.
> I'd be interested in doing an alternative server-side,
> one-click-install exe which handles the API (using your idea then
> initially a TW html side would be served containing the ZW plugin). I
> had a quick look at ziddlywiki.com but couldn't find an API description
> page...
Zope is, in general, non-trivial to install. But there are free hosting
solutions such as freezope.org where you can install a Zope server. So
it's more like (1) sign up for account at freezope (2) import
ZiddlyWiki. If you're counting clicks it's a lot more than two, but
nothing interesting was ever done with one click.
> I'm also interested in building-in an auto-javascript-instrumentation
> feature into such a server so as to more easily debug the TW/ZW plug-in
> at run-time. Such output from instrumented code could also be used as
> the basis for a test suite too.
See the firebug extension for Firefox, and my javascript shell:
http://bob.mcelrath.org/syntaxify.html#%5B%5BJavascript%20Shell%5D%5D
which is useful to poke and prod the code at runtime.
> > and my test site with the ZiddlyWikiPlugin:
> > http://ziddlywiki.com/test2.1#ZiddlyWikiPlugin
>
> Unfortunately here I got the following message using Firefox: 'Error: A
> script from "http://ziddlywiki.com" was denied UniversalBrowserRead
> privileges.'
Yes, it's in the testing phase... You'll have to allow
UniversalBrowserRead to use it. The latest thing I've been trying to do
is import/export, which runs up against the browser's cross-site
security mechanisms pretty hard.
SimonHF
> SimonHF [sim...@gmail.com] wrote:
> > If I understand correctly the ZiddlyWiki is currently a sort of
> > two-and-a-half-click-install solution... (1) download Zope, (2)
> > download ZiddlyWiki server-side scripts, (2.5) quickly configure & run.
> > I'd be interested in doing an alternative server-side,
> > one-click-install exe which handles the API (using your idea then
> > initially a TW html side would be served containing the ZW plugin). I
> > had a quick look at ziddlywiki.com but couldn't find an API description
> > page...
>
> Zope is, in general, non-trivial to install. But there are free hosting
> solutions such as freezope.org where you can install a Zope server. So
> it's more like (1) sign up for account at freezope (2) import
> ZiddlyWiki. If you're counting clicks it's a lot more than two, but
> nothing interesting was ever done with one click.
:-)
That's an interesting idea but I'd rather a solution which doesn't rely
on third parties or third party tools...
Seriously, what do yo think about formalizing the server API for ZW?
> > Unfortunately here I got the following message using Firefox: 'Error: A
> > script from "http://ziddlywiki.com" was denied UniversalBrowserRead
> > privileges.'
>
> Yes, it's in the testing phase... You'll have to allow
> UniversalBrowserRead to use it. The latest thing I've been trying to do
> is import/export, which runs up against the browser's cross-site
> security mechanisms pretty hard.
This is where I just don't know enough about JavaScript :-( A quick
Google says that the 'UniversalBrowserRead' error comes because you are
using two or more domains to grab your data from? Or is there another
reason?
Bob McElrath
> That's an interesting idea but I'd rather a solution which doesn't rely
> on third parties or third party tools...
At the very least, you need a web server. That is never trivial to
install.
> Seriously, what do yo think about formalizing the server API for ZW?
I think that's a fantastic idea. My time is limited however. If you
have the time to look at both ccTiddly and ZiddlyWiki and try to write
down a common subset...I'll take it very seriously, at least. I think
we can all benefit from this discussion.
I've discussed many aspects of this with Saq and coolcold WRT the
TiddlySnip firefox extension that Saq is writing. (Search the google
archives) With this, Saq wants to write to the server from TiddlySnip,
and he would benefit from a unified interface.
> This is where I just don't know enough about JavaScript :-( A quick
> Google says that the 'UniversalBrowserRead' error comes because you are
> using two or more domains to grab your data from? Or is there another
> reason?
That's it.
The page doesn't actually use that privilege, but does ask for it.
(It's needed if you save to a file and want to import from a http://
url) This is temporary. Again, a "testing" server.
google....@dfgh.net
*1 click install/run so you just need to send person A a file and he can start using - This is partially the case for server-side except for some simple installation procedure of your favorite server-side TW
*import/export of TW to single file version - this is available in cctiddly already (PS: import into db using uploadPlugin is not released yet, which would be available in ccT v1.1)
*single file mode have plugin to synchronize with server - interesting idea
*server mode have Load-on-demand - I also hope to implement this on ccTiddly
*notification of "user x editting tiddler y"
*standard server-side API - Bob and I has some discussion on this. This would not be stright forward but is a good thing to have
I don't quite understand the following though if you could clarify.
>By 'one click install' then I
mean a single 'exe' that one can download onto the desktop and start
and which then automatically starts the browser showing TW (the URL can
then simply be passed around to colleagues in an office environment, or
passed around to friends using, e.g., DynDNS for broadband/DSL home
users) -- in constrast to virtually all TW server-based derivatives
which rely on multiple third party tools being installed (e.g. Apache,
MySQL, Ruby, PHP, Perl, Java, etc).
I would love to hear about your further opinion as they are very valuable to us and the community.
Cheers,
CC
Simon Baird
Bob Denny
worth it seems to me like there's a risk of going over the top. Are you
trying to put the TiddlyWiki user interface in front of something
that's entirely different in purpose? If so, then do that. ALlso, my
personal opinion is that "it would be nice if..." really means "dump
the idea". Just do the "people are crying for a solution to
suchandsuch..." stuff Note I didn't say "a feature" because we all know
that feature requests are actually problem statements, and that more
often than not we can solve the problem in a simpler and more elegant
way, assuming we can see past the feature request and identify the real
problem!!! :-)
Jeremy Ruston
serverside API for TW, and support Bob's efforts to pluginise his
ZiddlyWiki extensions.
I'm very interested in using standards where we can, too. The standard
that seems particularly relevant is ATOM. As a thought experiment,
imagine what it would take to use Amazon's S3 service as a backend to
TiddlyWiki:
Cheers
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
SimonHF
> Sound like there are some interesting ideas floating around in the
> sever-side world :) I won't say I fully understand you but I'll try to make
> them into points to see if I have mis-understood.
>
> *1 click install/run so you just need to send person A a file and he can
> start using - This is partially the case for server-side except for some
> simple installation procedure of your favorite server-side TW
Right... and the wish is to reduce the 'simple installation procedure
of your favorite server-side TW' to something that non-technical-users
can handle, e.g. download exe onto Windows desktop & run it. There will
not even be any install procedure when the exe starts... it'll simply
run 'in place' and automatically start the web browser and show the
locally served TW web page... doing 'Load-on-demand' & 'user x editing
tiddler y' :-)
> *import/export of TW to single file version - this is available in cctiddly
> already (PS: import into db using uploadPlugin is not released yet, which
> would be available in ccT v1.1)
> *single file mode have plugin to synchronize with server - interesting idea
> *server mode have Load-on-demand - I also hope to implement this on ccTiddly
> *notification of "user x editting tiddler y"
> *standard server-side API - Bob and I has some discussion on this. This
> would not be stright forward but is a good thing to have
:-)
> I don't quite understand the following though if you could clarify.
> >By 'one click install' then I
> mean a single 'exe' that one can download onto the desktop and start
> and which then automatically starts the browser showing TW (the URL can
> then simply be passed around to colleagues in an office environment, or
> passed around to friends using, e.g., DynDNS for broadband/DSL home
> users) -- in constrast to virtually all TW server-based derivatives
> which rely on multiple third party tools being installed (e.g. Apache,
> MySQL, Ruby, PHP, Perl, Java, etc).
>
> I am not quite following this one. All server-side only requires you to
> setup once (MySQL+apache+PHP have 1-click install e.g. WAMP) and you can
> pass around the url for friends and family to use. Providing you want the
> functionality of being able to share your TW, it have to be hosted
> somewhere. This would always mean third party tool being employed.
Right... and this means that currently for using TW for collaboration
then one must at least know somebody who is a 'techie' who is willing
to initially perform that sequence of 1-click-installs... but what
about even doing away with the techies and just have a single exe file
which can be downloaded and run by *any* user? The exe would contain
its own web server, Tiddler storage mechanism, and TW html elements to
serve to clients...
And rather than creating one more TW variant I like the idea to
formalize a server API so that users and choose for example between the
download-and-run exe server (which is bound to have some limitations
but is never-the-less the most simple to get running) or a more
powerful server setup with MySQL / Apache / etc. Or have an upgrade
path from one solution to another etc.
google....@dfgh.net
CC
On 03/10/06, SimonHF - sim...@gmail.com <+google+coolcold+d4d0035c6e.simonhf#gmail.com@ spamgourmet.com> wrote:
google....@dfgh.net wrote:
> Sound like there are some interesting ideas floating around in the
> sever-side world :) I won't say I fully understand you but I'll try to make
> them into points to see if I have mis-understood.
>
> *1 click install/run so you just need to send person A a file and he can
> start using - This is partially the case for server-side except for some
> simple installation procedure of your favorite server-side TW
Right... and the wish is to reduce the 'simple installation procedure
of your favorite server-side TW' to something that non-technical-users
can handle, e.g. download exe onto Windows desktop & run it. There will
not even be any install procedure when the exe starts... it'll simply
run 'in place' and automatically start the web browser and show the
locally served TW web page... doing 'Load-on-demand' & 'user x editing
tiddler y' :-)
This can only be done for client TW unfortunately. I am afraid the simplest it can get is to
1/ apply for a free webhosting account (This isn't technical I believe)
2/ install server-side (setting config is the hardest part)
A possible solution is to use local version of TW with plugin as simon suggested earlier. However, it won't be accessable through the internet i.e. a person next door wont be able to access your file unless you two are on the same network
The one you've mentioned of mixing TW and a server (HTTP) could be tricky and not preferable since
1/ file size is larger (but a few MB unless 2)
2/ write a new server. Takes lots of time, security concern etc
3/ even if just bundling with apache, more time is required to setup the distribution package
4/ various flavour required, which is what you don't want in the first place.
I think you are more interested in a "service" where you want to register and have it running. I do hope to get that going in the future but there are some milestone I need to reach before getting there.
One question, have you looked at tiddlytools.com? It is very easy to setup (username and password) and it could be useful for you ;) If you don't have much editting to do among various people, you can use that to collaborate. Just remember to refresh before editting. Or you can ask nicely for a lock mechanism so you can lock it before you edit.
Hope it helps.
CC
SimonHF
> SimonHF [sim...@gmail.com] wrote:
> > That's an interesting idea but I'd rather a solution which doesn't rely
> > on third parties or third party tools...
>
> At the very least, you need a web server. That is never trivial to
> install.
...unless the web server is embedded within the exe that uses the
server API.
> > Seriously, what do yo think about formalizing the server API for ZW?
>
> I think that's a fantastic idea. My time is limited however. If you
> have the time to look at both ccTiddly and ZiddlyWiki and try to write
> down a common subset...I'll take it very seriously, at least. I think
> we can all benefit from this discussion.
Unfortunately, like you, my time is also limited. However, I will have
a go at examining the client / server traffic and writing it down. I
must first discover the best way to do this. Probably snooping the
ethernet traffic will be more effective than trying to understand the
Javascript. I already have a script which automatically instruments a
TW html file with debug code which logs each function call together
with the parameters that it was called with. This is interesting for
non-javascript-gurus to see much of what actually happens as one clicks
around in the browser. Maybe I can mix the javascript function log
dynamically with the snooped traffic of ccTiddly & ZiddlyWiki...
google....@dfgh.net
google....@dfgh.net wrote:
> Sound like there are some interesting ideas floating around in the
> sever-side world :) I won't say I fully understand you but I'll try to make
> them into points to see if I have mis-understood.
>
> *1 click install/run so you just need to send person A a file and he can
> start using - This is partially the case for server-side except for some
> simple installation procedure of your favorite server-side TW
Right... and the wish is to reduce the 'simple installation procedure
of your favorite server-side TW' to something that non-technical-users
can handle, e.g. download exe onto Windows desktop & run it. There will
not even be any install procedure when the exe starts... it'll simply
run 'in place' and automatically start the web browser and show the
locally served TW web page... doing 'Load-on-demand' & 'user x editing
tiddler y' :-)
1/ apply for a free webhosting account (This isn't technical I believe)
2/ install server-side (setting config is the hardest part)
A possible solution is to use local version of TW with plugin as simon suggested earlier. However, it won't be accessable through the internet i.e. a person next door wont be able to access your file unless you two are on the same network
The one you've mentioned of mixing TW and a server (HTTP) could be tricky and not preferable since
1/ file size is larger (but a few MB unless 2)
2/ write a new server. Takes lots of time, security concern etc
3/ even if just bundling with apache, more time is required to setup the distribution package
4/ various flavour required, which is what you don't want in the first place.
I think you are more interested in a "service" where you want to register and have it running. I do hope to get that going in the future but there are some milestone I need to reach before getting there.
One question, have you looked at tiddlytools.com? It is very easy to setup (username and password) and it could be useful for you ;) If you don't have much editting to do among various people, you can use that to collaborate. Just remember to refresh before editting. Or you can ask nicely for a lock mechanism so you can lock it before you edit.
Hope it helps.
CC
SimonHF
> Javascript. I already have a script which automatically instruments a
> TW html file with debug code which logs each function call together
> with the parameters that it was called with. This is interesting for
> non-javascript-gurus to see much of what actually happens as one clicks
Here is the first version of the tool for Windows without the snooping
functionality:
http://kalendarien.com/tw-instrumentor-v1-0.exe
The tool expects to find the TW as tw.html in the folder in which the
tool is started. This is what the output looks like when it is running:
C:\>tw-instrumentor-v1-0.exe
- starting
- reading: tw.html
- read bytes: 221960
- instrumenting javascript
- writing: tw-instrumented.html
- wrote bytes: 260943
- please load this file in your browser: tw-instrumented.html
- waiting for debug output (ctrl-c to exit)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Tue Oct 3 11:34:47 2006 config.macros.tabs.onClickTab (e=undefined)
Tue Oct 3 11:34:47 2006 config.macros.tabs.switchTab (tabset=[object]
tab=All)
Tue Oct 3 11:34:47 2006 createTiddlyElement (theParent=null
theElement=div theID=null theClass=tabContents theText=undefined)
Tue Oct 3 11:34:47 2006 TiddlyWiki.prototype.getTiddlerText
(title=TabAll defaultText=undefined)
Tue Oct 3 11:34:47 2006 this.fetchTiddler (title=TabAll)
Tue Oct 3 11:34:47 2006 TiddlyWiki.prototype.isShadowTiddler
(title=TabAll)
Tue Oct 3 11:34:47 2006 TiddlyWiki.prototype.getTiddler (title=TabAll)
Tue Oct 3 11:34:47 2006 this.fetchTiddler (title=TabAll)
Tue Oct 3 11:34:47 2006 wikify (source=<<list all>> output=[object]
highlightRegExp=null tiddler=null)
Tue Oct 3 11:34:47 2006 getParser (tiddler=null)
Tue Oct 3 11:34:47 2006 Wikifier (source=<<list all>>
formatter=[object Object] highlightRegExp=null tiddler=null)
Tue Oct 3 11:34:47 2006 Wikifier.prototype.subWikifyUnterm
(output=[object])
Tue Oct 3 11:34:47 2006 invokeMacro (place=[object] macro=list
params=all wikifier=[object Object] tiddler=null)
Tue Oct 3 11:34:47 2006 String.prototype.readMacroParams ()
Tue Oct 3 11:34:47 2006 String.prototype.parseParams (defaultName=list
defaultValue=null allowEval=true noNames=true
cascadeDefaults=undefined)
Tue Oct 3 11:34:47 2006 parseToken (match=all,,,,,all p=1)
...
Daniel Baird
> > One question, have you looked at tiddlytools.com? It is very easy to setup
> > (username and password) and it could be useful for you ;)
On 10/3/06, google....@dfgh.net <google....@dfgh.net> wrote:
> And I don't mean asking me, but the Daniel :p
>
> CC
Coolcold, do you mean tiddlyspot.com, rather than tiddlytools?
I'm with Jeremy, I think that TW will inevitably move toward a common
server side API.
I think that a good principle to follow when designing a server API
would be "the smarts should be in the client". So the server
operations could be a very simple set of primitives (which would mean
more implementations for more server languages and OSes).
Cheers
;Daniel
--
Daniel Baird
http://tiddlyspot.com (free, effortless TiddlyWiki hosting)
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog ::
Things That Suck)
SimonHF
simonhf wrote:
> > google....@dfgh.net wrote:
> A possible solution is to use local version of TW with plugin as simon
> suggested earlier. However, it won't be accessable through the internet i.e.
> a person next door wont be able to access your file unless you two are on
> the same network
Right... unless you use a service like this which allows even the
person next door to access your server:
https://www.dyndns.com/services/dns/dyndns/
> The one you've mentioned of mixing TW and a server (HTTP) could be tricky
> and not preferable since
> 1/ file size is larger (but a few MB unless 2)
> 2/ write a new server. Takes lots of time, security concern etc
> 3/ even if just bundling with apache, more time is required to setup the
> distribution package
I imagine that with an optional load-on-demand-from-server plugin (as
with ZiddlyWiki) then there would be two files to distrubute:
(1) tw-as-client-only.html <-- with is TW 'today'
(2) tw-server-with-tw-and-server-plugin.exe <-- this runs on the
desktop of the user and automatically launches TW with the
load-on-demand-from-server plugin
> 4/ various flavour required, which is what you don't want in the first
> place.
>
> I think you are more interested in a "service" where you want to register
> and have it running. I do hope to get that going in the future but there are
> some milestone I need to reach before getting there.
>
> One question, have you looked at tiddlytools.com? It is very easy to setup
> (username and password) and it could be useful for you ;) If you don't have
> much editting to do among various people, you can use that to collaborate.
> Just remember to refresh before editting. Or you can ask nicely for a lock
> mechanism so you can lock it before you edit.
Yes. It's a good idea, tiddlytool. However, the reason that I was
attracted to TW in the first place is because I was looking for a
light-weight and portable collaboration tool (obviously this isn't TW
right now but I immediately saw its potential to be one) for a small
corporate project where I'd never be allowed to host the project data
using a third party service such as tiddlytools :-(
google....@dfgh.net
I thin I'll give it a go and see on the common API.
Bob,
Would you mind me stealing some of ZW's javascript code?
CC
google....@dfgh.net
CC
SimonHF
> This is a very interesting tool. Does it matter where the TW file is
> located? Maybe this can act as an execute that upload the files after
Yes. Currently the very quickly hacked together program expects the TW
file to be called tw.html and be located in the same folder that the
exe is started, e.g.
c:\foo\tw-instrumentor.exe
c:\foo\tw.html
After running then the following file is created:
c:\foo\tw-instrumented.html
> editting as well. Or emulate a browser that catch user input in TW and
> updates it on a server. It's out of my scope though :(
The program currently adds JavaScript lines which send run-time info
back to the program thus creating a kind of run-time debug facility.
Bob McElrath
> Sorry, yes.....It must be the coffee.....I have been to tiddlytools too much
> lately. duh.
>
> I thin I'll give it a go and see on the common API.
>
> Bob,
>
> Would you mind me stealing some of ZW's javascript code?
Not at all!
Please start working from http://ziddlywiki.com/test2.1#ZiddlyWikiPlugin
which is a first stab at pluginifying ZW. This page is not ready for
prime time and contains a lot of debug code and experiments -- but you
should be able to grab the text of the plugin. Or go here:
http://ziddlywiki.com/ZiddlyWiki21/tiddlers/ZiddlyWikiPlugin
Tim Morgan released his code as public domain. I have put a GPL
statement on the above plugin but I've not thought much about it, and
Jeremy prefers BSD. At any rate, feel free to use this code as you see
fit. I'm willing to place my contributions so far in the public domain
if need be.
Please let me know what you do with this code, if we can make this
plugin common to ZW and ccTiddly, that would be fantastic.
Just a note about the API:
1) load/saves should be passing div's in both directions
2) I think a query string of some kind should be used for all
operations (rather than URL paths being significant)
3) We should isolate the information passed to the task at hand.
i.e. a "get tiddler" request shouldn't require authentication or
other server-specific information that is not in a non server-side
TW file.
4) The one thing I think we need to add is revision tracking. ZW
have done so with a single extended field, "revisionkey". Currently
this is a zope-specific string. This can be used in non-server-side
TW's to implement "undo" functionality. We should attempt to
formalize this usage, and maybe make it independent of the server.
I want to enable off-line edits and synchronization with the server,
using these revision keys.
google....@dfgh.net
Thanks for the link. I will start from merging the ajax functions first. I can't just dive in and change everything unfortunately and given ZW and ccT works differently, it would take some time to combine all the things. I'll try my best to follow your rules but will start with my plugins first since I am most familar with, and merge your plugins whenever possible. Will let you know when i have something to show.
CC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFFIpMMjwioWRGe9K0RAouSAJ0TH+CXy9VJRADhQrL0LE3IFkgoZACePHOS
cdOtYnde2AAvHseVziK9igg=
=r75X
-----END PGP SIGNATURE-----
Jeremy Ruston
wondered about the possibility of a server that's built out of
Mozilla's XULRunner project. It's let's you write cross-platform
applications in JavaScript in a browser-like environment that use
XP-COM to access low-level system operations like the network. See:
http://developer.mozilla.org/en/docs/XULRunner
As far as I can tell, XP-COM lets you do all the system stuff you
need, like listening on a socket. I'm not sure how threading would be
done, and there's loads of other things that may make it impossible,
even if just trying to support a dozen people in a workgroup.
But the attraction is that the server would essentially be a
server-side version of Firefox. If we're careful we could run almost
identical plugins on the serverside (eg, for generating RSS feeds).
If the first page that was served to a newly connecting client was a
completely statically served snapshot of the 'main' chunk of the
universe of tiddlers, we could actually actually scale quite well,
despite the apparent absurdity of using javascript on a server.
Cheers
Jeremy
SimonHF
> Regarding the suggestion of an easy to install server, I've often
> wondered about the possibility of a server that's built out of
> Mozilla's XULRunner project. It's let's you write cross-platform
> applications in JavaScript in a browser-like environment that use
> XP-COM to access low-level system operations like the network. See:
>
> http://developer.mozilla.org/en/docs/XULRunner
>
> As far as I can tell, XP-COM lets you do all the system stuff you
> need, like listening on a socket. I'm not sure how threading would be
> done, and there's loads of other things that may make it impossible,
> even if just trying to support a dozen people in a workgroup.
>
> But the attraction is that the server would essentially be a
> server-side version of Firefox. If we're careful we could run almost
> identical plugins on the serverside (eg, for generating RSS feeds).
This is an excellent idea but I would appeal *not* to do a XULRunner
specific version but rather go for the formalized server API so that
XULRunner is 'just another' sexy 'server' solution.
> If the first page that was served to a newly connecting client was a
> completely statically served snapshot of the 'main' chunk of the
> universe of tiddlers, we could actually actually scale quite well,
> despite the apparent absurdity of using javascript on a server.
Only problem that I see here is that when TW supports collaboration via
a server API then groups of users will produce Tiddlers at a far higher
rate and therefore the universe of Tiddlers could well be too large to
serve as a single snapshot. Interesting would be for the server to
remember the last Tiddlers open for a particular user and upload those
as a chunk. And/or for a user to be able to define some sort of regular
expression or rule which defines which chunk of the Tiddler universe to
include the snapshot -- which could also be the server-to-standalone-TW
export mechanism.
Then there is the question of how to perform the alert 'user x is
editing tiddler y'. Presumably the client will have to do some sort of
polling? (Or is there a way for a server to send a message to
JavaScript running on a client?) Therefore, it would actually be quite
good for a server to remember which Tiddlers have been served (even
with a snapshot) because then only alerts for those Tiddlers need be
served.
Jeremy Ruston
> specific version but rather go for the formalized server API so that
> XULRunner is 'just another' sexy 'server' solution.
Yes, it would use the same common HTTP-based API between the client
and the server as has been discussed with reference to ZiddlyWiki and
ccTiddly.
> Only problem that I see here is that when TW supports collaboration via
> a server API then groups of users will produce Tiddlers at a far higher
> rate and therefore the universe of Tiddlers could well be too large to
> serve as a single snapshot.
That's what I meant. The server would have an extensible mechanism for
figuring out which tiddlers to include. To begin with, it might be as
simple as "all of 'em", or just a tag expression, but ultimately, it
could log which popular additional tiddlers have been requested via
AJAX and merge them into the main distribution every so often.
DigglyWiki, if you like.
> Interesting would be for the server to
> remember the last Tiddlers open for a particular user and upload those
> as a chunk. And/or for a user to be able to define some sort of regular
> expression or rule which defines which chunk of the Tiddler universe to
> include the snapshot -- which could also be the server-to-standalone-TW
> export mechanism.
Exactly.
> Then there is the question of how to perform the alert 'user x is
> editing tiddler y'. Presumably the client will have to do some sort of
> polling? (Or is there a way for a server to send a message to
> JavaScript running on a client?) Therefore, it would actually be quite
> good for a server to remember which Tiddlers have been served (even
> with a snapshot) because then only alerts for those Tiddlers need be
> served.
Notifications like that can be useful but ultimately in an environment
where we sometimes have non-realtime sync, we have to cope with
collisions, and the WikiWay of reparing damage using the revision
history tool still seems like the best way. It scales surprisingly
well.
In the realtime collision case, doing something like writely.com is
possible, where the two users literally edit the same tiddler at the
same time, seeing each others changes instantaneously.
Anyway, notifications are still useful. As you say, in effect, the
server and the client would maintain a list of the tiddlers that the
client is 'watching'. The server would detect changes and piggyback
any outstanding notifications on the next HTTP request that happens to
be destined for that client (using HTTP headers). We'd still need
polling, or it may be possible to use a variation of Comet to do that:
http://alex.dojotoolkit.org/?p=545
Cheers
Jeremy.
SimonHF
> > Then there is the question of how to perform the alert 'user x is
> > editing tiddler y'. Presumably the client will have to do some sort of
> > polling? (Or is there a way for a server to send a message to
> > JavaScript running on a client?) Therefore, it would actually be quite
> > good for a server to remember which Tiddlers have been served (even
> > with a snapshot) because then only alerts for those Tiddlers need be
> > served.
>
> Notifications like that can be useful but ultimately in an environment
> where we sometimes have non-realtime sync, we have to cope with
> collisions, and the WikiWay of reparing damage using the revision
> history tool still seems like the best way. It scales surprisingly
> well.
>
> In the realtime collision case, doing something like writely.com is
> possible, where the two users literally edit the same tiddler at the
> same time, seeing each others changes instantaneously.
>
> Anyway, notifications are still useful. As you say, in effect, the
> server and the client would maintain a list of the tiddlers that the
> client is 'watching'. The server would detect changes and piggyback
> any outstanding notifications on the next HTTP request that happens to
> be destined for that client (using HTTP headers). We'd still need
> polling, or it may be possible to use a variation of Comet to do that:
>
> http://alex.dojotoolkit.org/?p=545
This looks really interesting. So if I understand correctly then the
browser JavaScript opens a 'keepalive' connection to the server which
is used for server-to-client notifications, while client-to-server
notifications are handled by additional non-keepalive connections from
browser Javascript to the server...? I searched for any example
JavaScript, handling the keepalive connection, but without luck :-(
Have you seen any examples?
Jeremy Ruston
>
> This looks really interesting. So if I understand correctly then the
> browser JavaScript opens a 'keepalive' connection to the server which
> is used for server-to-client notifications, while client-to-server
> notifications are handled by additional non-keepalive connections from
> browser Javascript to the server...? I searched for any example
> JavaScript, handling the keepalive connection, but without luck :-(
> Have you seen any examples?
I believe that writely.com uses the technique, and I guess there must
be some dojo demos showing it :)
Cheers
Jeremy
Bob McElrath
> Only problem that I see here is that when TW supports collaboration via
> a server API then groups of users will produce Tiddlers at a far higher
> rate and therefore the universe of Tiddlers could well be too large to
> serve as a single snapshot. Interesting would be for the server to
> remember the last Tiddlers open for a particular user and upload those
> as a chunk. And/or for a user to be able to define some sort of regular
> expression or rule which defines which chunk of the Tiddler universe to
> include the snapshot -- which could also be the server-to-standalone-TW
> export mechanism.
Are you thinking above that the server would not serve every tiddler to
the client? I've been thinking lately that for large TW's, the user
could load it from a file:// URL that would know of the server, and can
update itself when loaded. But each client would have all tiddlers that
way. This has a slightly easier time with AJAX browser security
restrictions than loading from a server.
> Then there is the question of how to perform the alert 'user x is
> editing tiddler y'. Presumably the client will have to do some sort of
> polling? (Or is there a way for a server to send a message to
> JavaScript running on a client?) Therefore, it would actually be quite
> good for a server to remember which Tiddlers have been served (even
> with a snapshot) because then only alerts for those Tiddlers need be
> served.
Currently ZiddlyWiki does lock tiddlers when a user hits the "edit"
button. This lock expires after a few minutes (I'd like to make this
more configurable). It's also possible to edit with ZW using any
WebDAV-enabled editor. I haven't enabled this in the TW UI, but I do it
all the time and ZW also obeys the WebDAV locks.
Currently ZW does poll the server every minute for updates. But I'd
like to make this configurable and/or smarter. I like the "Comet"
suggestion further down this thread. The server currently feeds the
client a list of tiddlers. For an example see here:
http://ziddlywiki.com/test2.1?action=login
the list contains the title and revisionkey, and since in ZW we also
have the revisionkey for each tiddler, the client figures out which have
been modified and reloads them individually. The "locked" attribute
could be easily passed here. And again a push model would work better
both for sending tiddler updates and locks. But as things stand
everything you've mentioned so far can be implemented (in a poll mode).
It looks like the "Comet" approach requires a long-running server
process per client that can keep track of open connections. This may be
quite hard or impossible on zope. Zope is transaction based... Then
again, there are tons of zope packages that do crazy things...
Jeremy Ruston
> the client? I've been thinking lately that for large TW's, the user
> could load it from a file:// URL that would know of the server, and can
> update itself when loaded. But each client would have all tiddlers that
> way. This has a slightly easier time with AJAX browser security
> restrictions than loading from a server.
Yeah, I think it makes sense to try to restrict the initially served
file to say <1MB. Some tiddlers would be left as empty stubs, just
taking up a few 10s of bytes for their metadata. The stubs would refer
to the URL from where they can be grabbed, which could either be a
REST HTTP server or a local file. When you grab a particular tiddler
from the server, you'd actually potentially drag back a clump of
tiddlers 'around' the one you asked for.
In terms of running as file: or http:, I'd like to support both modes,
as tiddlyspot and ziddlywiki do.
Cheers
Jeremy
>
> --
> Cheers,
> Bob McElrath [Univ. of California at Davis, Department of Physics]
>
> A people that values its privileges above its principles soon loses both.
> - Dwight Eisenhower
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFFI+XkjwioWRGe9K0RAjxBAKCxh22/18yQFSmN+Lbv1kmB4RUeEwCfXbVU
> a+2TQEw221fhA21YtmY0MpU=
> =YHkm
Bob McElrath
> Yeah, I think it makes sense to try to restrict the initially served
> file to say <1MB. Some tiddlers would be left as empty stubs, just
> taking up a few 10s of bytes for their metadata. The stubs would refer
> to the URL from where they can be grabbed, which could either be a
> REST HTTP server or a local file. When you grab a particular tiddler
> from the server, you'd actually potentially drag back a clump of
> tiddlers 'around' the one you asked for.
If you're going to serve a subset of tiddlers, how do you decide which
ones? Ones with shadow tiddlers are obvious, but what about the rest?
Why not serve an empty TW file with a list of tiddlers (like the one
demonstrated in a previous email) and load everything on demand?
I'm not sure that one can make a sensible subset, except the minimal
subset.
Jeremy Ruston
> ones? Ones with shadow tiddlers are obvious, but what about the rest?
>
> Why not serve an empty TW file with a list of tiddlers (like the one
> demonstrated in a previous email) and load everything on demand?
>
> I'm not sure that one can make a sensible subset, except the minimal
> subset.
I think there are some strong advantages to trying to serve a critical
mass of content. It makes the system more resilient, for instance
ensuring that people can see *something* even if xmlhttprequest isn't
available.
I suspect that most of the TW files on tiddlyspot or anywhere else are
actually perfectly practical to serve in one gulp. I'd imagine a
starter algorithm that does some basic things if the all-in-one
approach exceeds the size limit, like trying to remove any
disproportionately large tiddlers first. You could do link analysis to
get the n-generations of links from the starter tiddlers like
MainMenu.
Bear in mind that I'm suggesting that an advantage of this approach is
that it allows the starter file to be generated by a batch process,
and served statically. I'm very keen on client-server architectures
that improve performance by judicious use of static files. Serving
them is the one thing that the web's infrastructure does a reasonable
job of optimising:
"You might say 'duh', but people often overlook the obvious; with
event-looped Web servers like lighttpd (see c10k for more
information), you can get 2-3 orders of magnitude more requests/second
over LAMP and similar applications."
from:
http://www.mnot.net/blog/2006/05/16/web_2_caching
Click through to the slides:
http://www.mnot.net/papers/web_2_speed.pdf
Cheers
Jeremy
google....@dfgh.net
CC
SimonHF
> Is it possible to include the TW code into the exe as well?
Yes but the exe currently only handles one TCP/IP socket so it's not
much use. I will create a multi socket exe and then things will start
to get interesting. First thing on the agenda is to get a working
'Comet' prototype with bidirectional, non-polling client - server
communication.
> and is it difficult to write an FTP client?
In theory this is not difficult. What do yo have in mind?
SimonHF
> > > http://alex.dojotoolkit.org/?p=545
> >
> > This looks really interesting. So if I understand correctly then the
> > browser JavaScript opens a 'keepalive' connection to the server which
> > is used for server-to-client notifications, while client-to-server
> > notifications are handled by additional non-keepalive connections from
> > browser Javascript to the server...? I searched for any example
> > JavaScript, handling the keepalive connection, but without luck :-(
> > Have you seen any examples?
>
> I believe that writely.com uses the technique, and I guess there must
> be some dojo demos showing it :)
I haven't have a look at the writely.com JS yet but I have Googled
around a bit. It seems that there are several difficulties:
(1) The XMLHTTPRequest spec. supports readyState==3 which means 'Some
data has been received.' but according to various internet sources then
this state is badly supported and implemented different across
browsers, e.g. one browser only ever calls it once, another only calls
it every 4096 bytes, etc.
(2) So let's imagine that we don't try to use readyState==3 and instead
the client sends the XMLHTTPRequest, the server sends some headers, and
then the server waits until a comet-like notification needs to be sent
and sends it. Then the client uses readyState==4 as usual but then
needs to issue another XMLHTTPRequest for the next server notification.
However, here we seem to run into another problem with timeouts
described here:
http://www.thescripts.com/forum/thread437421.html
The only solution to avoid a timeout appears to be for the server to
feed the client with a dummy character of output every now and then.
This would still be much cheaper than the client polling for irregular
server notifications.
Udo Borkowski
The one thing I am missing in all I have read so far is a function that
takes care of the "search" feature. I am not sure how the existing
server side implementations are dealing with this (all done on client
side?) but I guess having some server side support for this would be
fine. Also supporting other "search methods" (e.g. the one used in the
YourSearchPlugin, with boolean search etc.) would be fine.
The same may be true for other "iterations" over the tiddlers of the
TiddyWiki (like to create the various lists etc.)
Any ideas?
Udo
SimonHF wrote:
>(Sorry: I posted this message to the other NG without realizing that
>this 'Dev' NG exists...)
>
>It seems to me that the main reason why TW is so well loved is because
>all scripts & data are included within one convenient html file.
>However, it is such a pity that there is no standard solution for
>multi-user access. And, more importantly, no up-and-coming 'one click
>install' solution for multi-user access. By 'one click install' then I
>mean a single 'exe' that one can download onto the desktop and start
>and which then automatically starts the browser showing TW (the URL can
>then simply be passed around to colleagues in an office environment, or
>passed around to friends using, e.g., DynDNS for broadband/DSL home
>users) -- in constrast to virtually all TW server-based derivatives
>which rely on multiple third party tools being installed (e.g. Apache,
>MySQL, Ruby, PHP, Perl, Java, etc). Ideally it would be possible for
>such an executable to not only serve individual Tiddlers (for usual
>server-based interactive use) but also to serve (or import) large(r)
>sets of Tiddlers which are effectively 'exported' or 'imported' for
>off-line use. Such an exported set of Tiddlers would effectively be
>very similar to the single TW html file that we all know and love
>today.
>
>How to achieve this? TW could detect automatically whether it has been
>started from a file or from the special TW server. In file mode then TW
>would behave like it does today, with the exception of extra
>functionality to synchronize its Tiddlers with a particular TW server.
>In server mode then TW would fetch all Tiddlers dynamically via AJAX /
>Web2.0 asynchronous technology, and there would be notifications like
>'user x is editing this tiddler since ...' etc. The thing is that there
>would still be just one set of TW JavaScript which behaves differently
>depending upon how the TW is started.
>
>Further, I imagine a generic TW server API so that not only can we come
>up with the 'one click install' TW but also other developers can create
>TW server solutions using the standard TW server API but using their
>favorite third party tools, e.g. Apache, MySQL, or whatever.
>
>Comments?
>
>
>>
>
>
>
Greg Wolff
decide what to discard from the cache.
It would be straightforward to implement on the server-side. Once the
static file has exceeded some threshold, replace the tiddlers with
"oldest access times" by stubs. When a client makes a request for a
Tiddler, update the access time for that tiddler and add it back to the
static file.
This could be augmented by keeping track of accesses (views) on the
client. Keeping track of this info would also be useful in other ways,
for example listing Tiddlers by "most viewed" (a feature that would be
very helpful for me).
Of course, none of this helps with files that have lots of large
plugins since all of the systemConfig tiddlers need to be in the static
download anyway.
-Greg
On Oct 4, 10:26 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> > If you're going to serve a subset of tiddlers, how do you decide which
> > ones? Ones with shadow tiddlers are obvious, but what about the rest?
>
> > Why not serve an empty TW file with a list of tiddlers (like the one
> > demonstrated in a previous email) and load everything on demand?
>
> > I'm not sure that one can make a sensible subset, except the minimal
> > subset.I think there are some strong advantages to trying to serve a critical
SimonHF
> be some dojo demos showing it :)
Okay... here's a comet demo:
http://kalendarien.com/comet-chat-server-demo-v1-0.exe
What it does:
- Real-time multi-browser javascript chat via comet (i.e. no polling).
- Single exe runs where-ever you download it without installation
necessary.
- Automatically starts IE with the correct URL.
- Test with IE, FF, & Opera.
- There are a few http server bugs... it's only hacked together
quickly.
Once there is a standard TW API then the demo shows how things could
be... with 'user x editing tiddler y' notifications etc.
SimonHF
> - Real-time multi-browser javascript chat via comet (i.e. no polling).
Er... forgot to mention that it's necessary to open a 2nd, 3rd, 4th,
etc browser session to see the comet mechanism in action... the demo
only open one IE window at the start...