Discussion:
[twdev] [TW5] "soft reboot"?
(too old to reply)
TheDiveO
2014-10-12 19:17:02 UTC
Permalink
In my quest for developing TW5 modules from inside a web browser I would
like to ask whether it could be possible to soft reboot an in-browser TW5
instance? How about writing the current TW5 state instead of to an external
file now back into the DOM? This is not about rendering, but persistence
through the DOM. Shouldn't this make a reboot of the TW5 core possible?

Regards,
TheDiveO
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2014-10-13 08:36:21 UTC
Permalink
Hi TheDiveO
Post by TheDiveO
In my quest for developing TW5 modules from inside a web browser I would
like to ask whether it could be possible to soft reboot an in-browser TW5
instance? How about writing the current TW5 state instead of to an external
file now back into the DOM? This is not about rendering, but persistence
through the DOM. Shouldn't this make a reboot of the TW5 core possible?
Just to be clear, what would the differences be between a soft reboot and a
full reboot of refreshing the browser window?

Best wishes

Jeremy.
Post by TheDiveO
Regards,
TheDiveO
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Ruston
mailto:***@gmail.com
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
TheDiveO
2014-10-13 10:17:57 UTC
Permalink
Ups, forgot to explain that: a soft reboot does not involve reloading the
whole TW5 instance from a web server (such as a Node.js TW5 instance).
Instead, a soft reboot would simply update the "persistent" in-browser TW5
representation and then reboot it, similar to a clean load but without any
network communication. In addition, I imagine that more TW5 state could be
persisted across a soft reboot but not about a reload. Such as: the state
of the story river and of the UI elements, where possible.

Would this make sense?

Regards,
TheDiveO
Post by Jeremy Ruston
Hi TheDiveO
Post by TheDiveO
In my quest for developing TW5 modules from inside a web browser I would
like to ask whether it could be possible to soft reboot an in-browser TW5
instance? How about writing the current TW5 state instead of to an external
file now back into the DOM? This is not about rendering, but persistence
through the DOM. Shouldn't this make a reboot of the TW5 core possible?
Just to be clear, what would the differences be between a soft reboot and
a full reboot of refreshing the browser window?
Best wishes
Jeremy.
Post by TheDiveO
Regards,
TheDiveO
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Ruston
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2014-10-14 09:43:30 UTC
Permalink
Hi TheDiveO
Post by TheDiveO
Ups, forgot to explain that: a soft reboot does not involve reloading the
whole TW5 instance from a web server (such as a Node.js TW5 instance).
Why do you want to avoid reloading the page from the web server?

Instead, a soft reboot would simply update the "persistent" in-browser TW5
Post by TheDiveO
representation and then reboot it,
What do you mean by persistent in-browser TW5 representation?
Post by TheDiveO
similar to a clean load but without any network communication. In
addition, I imagine that more TW5 state could be persisted across a soft
reboot but not about a reload. Such as: the state of the story river and of
the UI elements, where possible.
All of TW5's state is stored in tiddlers, including the state of the story
river and UI elements.

Perhaps an alternative way to explore this would be if you could outline
the user experience/benefits that your aiming for?

It seems as though you want to introduce a new way of restarting the wiki
in the browser that doesn't do as much work as a full reload. The bit that
I'm not seeing is how you could reduce the work done on the restart without
changing the semantics of restarting. It's no good us providing a warm
reboot for plugin writers to use in testing unless it precisely mirrors the
behaviour of a restart that the plugin will experience in the field.

For example, what if an errant plugin module creates a whole bunch of
browser global variables, or attaches event handlers to document.body. How
are you going to ensure that those side-effects get cleaned up over a warm
reboot?

Best wishes

Jeremy.
Post by TheDiveO
Would this make sense?
Regards,
TheDiveO
Post by Jeremy Ruston
Hi TheDiveO
Post by TheDiveO
In my quest for developing TW5 modules from inside a web browser I would
like to ask whether it could be possible to soft reboot an in-browser TW5
instance? How about writing the current TW5 state instead of to an external
file now back into the DOM? This is not about rendering, but persistence
through the DOM. Shouldn't this make a reboot of the TW5 core possible?
Just to be clear, what would the differences be between a soft reboot and
a full reboot of refreshing the browser window?
Best wishes
Jeremy.
Post by TheDiveO
Regards,
TheDiveO
--
You received this message because you are subscribed to the Google
Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Ruston
--
Jeremy Ruston
mailto:***@gmail.com
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
TheDiveO
2014-10-14 11:59:57 UTC
Permalink
Post by Jeremy Ruston
Hi TheDiveO
Post by TheDiveO
Ups, forgot to explain that: a soft reboot does not involve reloading the
whole TW5 instance from a web server (such as a Node.js TW5 instance).
Why do you want to avoid reloading the page from the web server?
Why should I need and thus avoid the round trip? At the moment, after
reload the story river tiddler state is gone, as is the precise sidebar
state bar. Of course, this is not the prime reason d'être ... but an
important reason is that I don't want to persist the exact story river and
sidebar states into my filesystem and thus the repository.
Post by Jeremy Ruston
Instead, a soft reboot would simply update the "persistent" in-browser TW5
Post by TheDiveO
representation and then reboot it,
What do you mean by persistent in-browser TW5 representation?
When you receive the single-file TW5 instance over the "network" from your
Node.js-based TW5 server, this single file contains the tiddlers made
"persistent" inside the HTML markup. When TW5 boots it unpacks this
"persistent representation" into the live JavaScript objects. While we can
dump an HTML markup representation for saving we cannot(?) currently write
back the current state of the JavaScript objects into the in-browser HTML
markup DOM representation from which we once booted. This HTML markup
loaded inside the browser and later booted is what I call the "persistent
in-browser TW5 representation". It's persistent not in the sense that it is
persistent on the file system but it is (kind of limited) persistent inside
the web browser page unless you are reloading it. Rebooting would not be
reloading and thus would mean to restart from the most recent HTML markup
with the recent state of tiddlers stored inside this markup.
Post by Jeremy Ruston
Post by TheDiveO
similar to a clean load but without any network communication. In
addition, I imagine that more TW5 state could be persisted across a soft
reboot but not about a reload. Such as: the state of the story river and of
the UI elements, where possible.
All of TW5's state is stored in tiddlers, including the state of the story
river and UI elements.
But many of this state on purpose does not get synced back to a Node.js TW5
server instance, correct? I would like to not change this in order to not
mess up my source repository. But I would like to sync back this current
state into the HTML markup from which my current TW5 instance inside my
browser window was booted ... and then reboot this HTML markup, kind of
warm reboot then.
Post by Jeremy Ruston
Perhaps an alternative way to explore this would be if you could outline
the user experience/benefits that your aiming for?
- Reloading changed module implementations without loosing the overall
state the TW5 instance you are currently editing:
- story river seemingly unchanged, except to the changes caused by
most recent module implementations.
- sidebar seemingly unchanged, tabs open where you were just before
the reboot.
- No need to reopen the story river and thus all the system tiddlers you
were working on; for me, often some module tiddlers and some test tiddlers.
- Avoid tedious and time-consuming task of bringing your reloaded TW5
instance up to the point where you needed it to reboot after module changes.
Post by Jeremy Ruston
It seems as though you want to introduce a new way of restarting the wiki
in the browser that doesn't do as much work as a full reload. The bit that
I'm not seeing is how you could reduce the work done on the restart without
changing the semantics of restarting. It's no good us providing a warm
reboot for plugin writers to use in testing unless it precisely mirrors the
behaviour of a restart that the plugin will experience in the field.
With our discusssion of hot plug in my mind I would not change the restart
procedure; instead I would like to make sure that certain status
information survives into the next boot procedure. My impression is that by
storing back the exact state information into the HTML markup and then
executing the usual boot I could end up with (almost) the same state where
I took off for reboot.
Post by Jeremy Ruston
For example, what if an errant plugin module creates a whole bunch of
browser global variables, or attaches event handlers to document.body. How
are you going to ensure that those side-effects get cleaned up over a warm
reboot?
My idea of "warm" reboot is to do a normal (clean) boot but with the only
that state information preserved that normally doesn't get writting back to
a TW5 server instance. That is, story river state and side bar state. This
would **not** include the internal program state. Only the TW5 tiddler
"state".

*All this under the assumption that we have enough such tiddler state that
we can recreate the illusion of a warm "re"boot, when in fact it is a
normal boot just with more complete state.* Feasible?

Thank you for the interesting discussion! I'm really fascinated how this
will turn out...
TheDiveO
Post by Jeremy Ruston
Best wishes
Jeremy.
Post by TheDiveO
Would this make sense?
Regards,
TheDiveO
Post by Jeremy Ruston
Hi TheDiveO
Post by TheDiveO
In my quest for developing TW5 modules from inside a web browser I
would like to ask whether it could be possible to soft reboot an in-browser
TW5 instance? How about writing the current TW5 state instead of to an
external file now back into the DOM? This is not about rendering, but
persistence through the DOM. Shouldn't this make a reboot of the TW5 core
possible?
Just to be clear, what would the differences be between a soft reboot
and a full reboot of refreshing the browser window?
Best wishes
Jeremy.
Post by TheDiveO
Regards,
TheDiveO
--
You received this message because you are subscribed to the Google
Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Ruston
--
Jeremy Ruston
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2014-10-15 17:09:24 UTC
Permalink
Hi TheDiveO
Post by TheDiveO
Why should I need and thus avoid the round trip? At the moment, after
reload the story river tiddler state is gone, as is the precise sidebar
state bar. Of course, this is not the prime reason d'être ... but an
important reason is that I don't want to persist the exact story river and
sidebar states into my filesystem and thus the repository.

If the state were all persisted back to the filesystem presumably you could
exclude them from the file system in .gitignore?
Post by TheDiveO
But many of this state on purpose does not get synced back to a Node.js
TW5 server instance, correct? I would like to not change this in order to
not mess up my source repository. But I would like to sync back this
current state into the HTML markup from which my current TW5 instance
inside my browser window was booted ... and then reboot this HTML markup,
kind of warm reboot then.

I think this is the crux of the matter. We want to have persistent state so
that we can refresh the browser without any change to the UI. There's a
mechanism in place to do that in the shape of the syncer and adaptors - the
issue of some state not getting synced is actually just a quick hack to
enable multiple users to coexist without overwriting one anothers state.

Your suggestion of a new state persistence mechanism reminds me of another
requirement: in multiuser environments like TiddlySpot it would be very
convenient if we could persist usernames at the browser level (presumably
with localStorage). The idea would be some kind of filter that determines
that certain tiddlers are ignored by the syncer and instead are stored in
local storage. Then at startup we'd have the option to load those tiddlers.

You might experiment with modifying the syncer filter to remove the state
tiddlers:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core%2Fwiki%2Fconfig%2FSyncFilter.tid

The other thing that's needed would be to open the current story list
instead of the default tiddlers at startup. That can be done by setting
default tiddlers to [list[$:/StoryList]].

Best wishes

Jeremy
Post by TheDiveO
Post by Jeremy Ruston
Hi TheDiveO
Post by TheDiveO
Ups, forgot to explain that: a soft reboot does not involve reloading
the whole TW5 instance from a web server (such as a Node.js TW5 instance).
Why do you want to avoid reloading the page from the web server?
Why should I need and thus avoid the round trip? At the moment, after
reload the story river tiddler state is gone, as is the precise sidebar
state bar. Of course, this is not the prime reason d'être ... but an
important reason is that I don't want to persist the exact story river and
sidebar states into my filesystem and thus the repository.
Post by Jeremy Ruston
Instead, a soft reboot would simply update the "persistent" in-browser
Post by TheDiveO
TW5 representation and then reboot it,
What do you mean by persistent in-browser TW5 representation?
When you receive the single-file TW5 instance over the "network" from your
Node.js-based TW5 server, this single file contains the tiddlers made
"persistent" inside the HTML markup. When TW5 boots it unpacks this
"persistent representation" into the live JavaScript objects. While we can
dump an HTML markup representation for saving we cannot(?) currently write
back the current state of the JavaScript objects into the in-browser HTML
markup DOM representation from which we once booted. This HTML markup
loaded inside the browser and later booted is what I call the "persistent
in-browser TW5 representation". It's persistent not in the sense that it is
persistent on the file system but it is (kind of limited) persistent inside
the web browser page unless you are reloading it. Rebooting would not be
reloading and thus would mean to restart from the most recent HTML markup
with the recent state of tiddlers stored inside this markup.
Post by Jeremy Ruston
Post by TheDiveO
similar to a clean load but without any network communication. In
addition, I imagine that more TW5 state could be persisted across a soft
reboot but not about a reload. Such as: the state of the story river and of
the UI elements, where possible.
All of TW5's state is stored in tiddlers, including the state of the
story river and UI elements.
But many of this state on purpose does not get synced back to a Node.js
TW5 server instance, correct? I would like to not change this in order to
not mess up my source repository. But I would like to sync back this
current state into the HTML markup from which my current TW5 instance
inside my browser window was booted ... and then reboot this HTML markup,
kind of warm reboot then.
Post by Jeremy Ruston
Perhaps an alternative way to explore this would be if you could outline
the user experience/benefits that your aiming for?
- Reloading changed module implementations without loosing the overall
- story river seemingly unchanged, except to the changes caused by
most recent module implementations.
- sidebar seemingly unchanged, tabs open where you were just before
the reboot.
- No need to reopen the story river and thus all the system tiddlers
you were working on; for me, often some module tiddlers and some test
tiddlers.
- Avoid tedious and time-consuming task of bringing your reloaded TW5
instance up to the point where you needed it to reboot after module changes.
Post by Jeremy Ruston
It seems as though you want to introduce a new way of restarting the wiki
in the browser that doesn't do as much work as a full reload. The bit that
I'm not seeing is how you could reduce the work done on the restart without
changing the semantics of restarting. It's no good us providing a warm
reboot for plugin writers to use in testing unless it precisely mirrors the
behaviour of a restart that the plugin will experience in the field.
With our discusssion of hot plug in my mind I would not change the restart
procedure; instead I would like to make sure that certain status
information survives into the next boot procedure. My impression is that by
storing back the exact state information into the HTML markup and then
executing the usual boot I could end up with (almost) the same state where
I took off for reboot.
Post by Jeremy Ruston
For example, what if an errant plugin module creates a whole bunch of
browser global variables, or attaches event handlers to document.body. How
are you going to ensure that those side-effects get cleaned up over a warm
reboot?
My idea of "warm" reboot is to do a normal (clean) boot but with the only
that state information preserved that normally doesn't get writting back to
a TW5 server instance. That is, story river state and side bar state. This
would **not** include the internal program state. Only the TW5 tiddler
"state".
*All this under the assumption that we have enough such tiddler state that
we can recreate the illusion of a warm "re"boot, when in fact it is a
normal boot just with more complete state.* Feasible?
Thank you for the interesting discussion! I'm really fascinated how this
will turn out...
TheDiveO
Post by Jeremy Ruston
Best wishes
Jeremy.
Post by TheDiveO
Would this make sense?
Regards,
TheDiveO
Post by Jeremy Ruston
Hi TheDiveO
Post by TheDiveO
In my quest for developing TW5 modules from inside a web browser I
would like to ask whether it could be possible to soft reboot an in-browser
TW5 instance? How about writing the current TW5 state instead of to an
external file now back into the DOM? This is not about rendering, but
persistence through the DOM. Shouldn't this make a reboot of the TW5 core
possible?
Just to be clear, what would the differences be between a soft reboot
and a full reboot of refreshing the browser window?
Best wishes
Jeremy.
Post by TheDiveO
Regards,
TheDiveO
--
You received this message because you are subscribed to the Google
Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Ruston
--
Jeremy Ruston
--
Jeremy Ruston
mailto:***@gmail.com
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
Loading...