Voicing Futures ...

[@TiddlyTweeter]

Here is a discussion I and Jeremy Ruston started, privately, on Twitter. We realised that it could just as well be public in case anyone else wants to read / comment ...

Josiah, 1...

Are we all doomed to have to give up on simple download file-saving?

Do you know if the excellent TiddlyFox 2 will still work after the ominous Firefox 57?

WHY do Mozilla take so LONG approving add-ons?

WHY do you keep TiddlyFox on Mozilla add-ons marked as "Experimental"?

Best wishes
Josiah

Jeremy, 1...

By “simple download file saving” do you mean the default fall back HTML 5 saver? I’ve no idea about Firefox 57. I’ve no idea why Mozilla do what they do. I mark it experimental to save it going through Mozilla’s more rigorous full review.

Josiah, 2...

Ciao Jeremy. I guess where I am coming from is as a "naive" user (well, I'm pretending to be one & try stay in that skin a bit).

I'm trying to get my head round the stumbling blocks to better uptake of TW.

No. On "saving" I mean what TiddlyFox does brilliantly, simply. Overwrite. The fallback behaviour of save(1) save(2) is not viable, IMO, for most folk.

On Mozilla ... on everything I read they are internally confident in what they are doing ... just about everything else is like witnessing shooting into the foot. It all gets too convoluted.

I now understand why you keep it "experimental". From a naive user point of view its a slight put-off. I'm not sure but does the latest v1 still work in FF 52. 57 is when they say they will go wholly WebExtensions: Firefox 57 - Compatability Milestone

Jeremy, 2...

Here’s the thing: all the difficulties in getting started with TiddlyWiki stem from the single file architecture. It’s fiddly and unfamiliar to most people. The simple fix is to move it to an online service, when all those problems melt away. Simple. If on the other hand, anyone wants the considerable advantages of working offline without a server, well, then TiddlyWiki is the only thing on the planet that can help them, and it comes with a learning curve. That’s life.

Jeremy, 3...

My sense is that you are pushing to find a way for the standalone HTML file experience to match the ease of use of an online service. I don’t think that’s possible.

[Mark S.]

If you had read any javascript book from the 90s, they would have assured you that you couldn't write or change client-side code to the local file system. What TW/TW5 managed to do for so long was nearly miraculous.

In terms of workarounds, I can imagine a small batch file on the desktop that would find the last version of a created html TW file, copy it to it's intended start directory, and then launch it in the web-browser. The batch file equivalent would need to be written for whatever platform and/or technologies were available. 

Speaking of technologies, is  it no longer possible to use a signed java applet to save changes?

Mark

[Jon]

Josiah,

You seem to be pushing for something which you see as inconvenient without appreciating the underlying complexities involved, which as a "naive" user myself, I can only guess at. 

I just think that if there was a quick fix to this issue, Jeremy would have already introduced it.

Regards

Jon

[Ákos Szederjei]

Jon, I do not think I (we) lack the appreciation for the complexities of the
problem. As a user, we bow to the Almighty Powers of The Developers, but I
think you underestimate how important an easy save feature is, as we have it
now.

The problem as we see it, is very relevant to the use and spread of TW. In my
opinion, to have an easy save option is not a "nice to have feature" or a
question of (in)convenience. I use TW on Linux without it, and I lost lot of
work because I closed browser / tab accidentally or because I simply forgot
to save. TW is capabilities are way to complex to not to have an "auto" save
feature.

I also disagree with the assumption that the save option is a server side
feature. I understand the notion why it is easier to have that on a server
side based wiki. I am not saying we need to have the same functionality as a
server side wiki. There are many solutions, besides plug ins, which were
listed before by the members of this list. Currently we do not have a platform
independent solution for the problem.

Maybe I am overestimating the problem, that would be valid answer I accept,
yet disagree with.

I rest my case. :)

Ákos

On Montag, 13. März 2017 07:38:14 CET Jon wrote:
> Josiah,
>
> You seem to be pushing for something which you see as inconvenient without
> appreciating the underlying complexities involved, which as a "naive" user
> myself, I can only guess at.
> I just think that if there was a quick fix to this issue, Jeremy would have
> already introduced it.
>
> Regards
> Jon
>
> On Sunday, 12 March 2017 14:01:50 UTC, @TiddlyTweeter wrote:

> > *Here is a discussion I and Jeremy Ruston started, privately, on Twitter.

> > We realised that it could just as well be public in case anyone else wants

> > to read / comment ... *
> >
> > *Josiah, 1... *

> > Are we all doomed to have to give up on simple download file-saving?
> >
> > Do you know if the excellent TiddlyFox 2 will still work after the ominous
> > Firefox 57?
> >
> > WHY do Mozilla take so LONG approving add-ons?
> >
> > WHY do you keep TiddlyFox on Mozilla add-ons marked as "Experimental"?
> >
> > Best wishes
> > Josiah
> >
> >

> > *Jeremy, 1...*

> > By “simple download file saving” do you mean the default fall back HTML 5
> > saver? I’ve no idea about Firefox 57. I’ve no idea why Mozilla do what
> > they
> > do. I mark it experimental to save it going through Mozilla’s more
> > rigorous
> > full review.
> >
> >

> > *Josiah, 2...*

> > Ciao Jeremy. I guess where I am coming from is as a "naive" user (well,
> > I'm pretending to be one & try stay in that skin a bit).
> >
> > I'm trying to get my head round the stumbling blocks to better uptake of
> > TW.
> >
> > No. On "saving" I mean what TiddlyFox does brilliantly, simply. Overwrite.
> > The fallback behaviour of save(1) save(2) is not viable, IMO, for most
> > folk.
> >
> > On Mozilla ... on everything I read they are internally confident in what
> > they are doing ... just about everything else is like witnessing shooting
> > into the foot. It all gets too convoluted.
> >
> > I now understand why you keep it "experimental". From a naive user point
> > of view its a slight put-off. I'm not sure but does the latest v1 still
> > work in FF 52. 57 is when they say they will go wholly WebExtensions:
> > Firefox 57 - Compatability Milestone

> > <https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compati
> > bility-milestones/>
> >
> > *Jeremy, 2...*

> > Here’s the thing: all the difficulties in getting started with TiddlyWiki
> > stem from the single file architecture. It’s fiddly and unfamiliar to most
> > people. The simple fix is to move it to an online service, when all those
> > problems melt away. Simple. If on the other hand, anyone wants the
> > considerable advantages of working offline without a server, well, then
> > TiddlyWiki is the only thing on the planet that can help them, and it
> > comes
> > with a learning curve. That’s life.
> >

> > *Jeremy, 3...*

[Jon]

Hi Akos,

I'm really not qualified to comment. All I'd say is that the impression I have from Jeremy's and other's responses to this question is that the reasons the save issue hasn't been solved is due to technical difficulties rather than not appreciating how important having an easy saving mechanism is, especially for new users etc.

I'm sure someone else will be able to clarify the position.

Regards

Jon

[@TiddlyTweeter]

Ciao Mark S., Ákos & Jon

BACKUP. Because of the importance of work I now do in TW, complementing the excellent TiddlyFox auto-save, I run a resident ("redundant") backup program that detects file changes in my TWs every 30 minutes. I simply cannot afford to lose work. Basically BACKUP can be handled and is, I think, quite manageable with the many tools around. But you can't backup what you haven't saved.

RE-ENTRANT SAVING. In the discussion with Jeremy there is a lot. Especially in his second comment. Opening that up, what it implies in detail, is I think very interesting.
         One aspect of it is, centrally, whether in the future, RE-ENTRANT SAVING will still be possible (i.e. via some gadget in the browser) or not. I think that matters. I understand that the way browsers are going is making it harder than ever. That was a large part of where I was coming from. I STILL think that a TW that can save over itself as a standalone is not something to give up on entirely quite yet.
         And, perhaps naively, I believe its still quite important to wider uptake of TW.

Best wishes
Josiah

[Eric Shulman]

On Sunday, March 12, 2017 at 7:01:50 AM UTC-7, @TiddlyTweeter wrote:

The fallback behaviour of save(1) save(2) is not viable, IMO, for most folk. 

First... a bit of history to provide a bit of perspective on how we came to be here...

Many years ago, browsers permitted "privileged file I/O" operations from Javascript simply by making a call to "request permissions".  This would display a dialog box that would ask the user to allow direct file I/O.   Once permitted, that choice could be remembered, so that further saving would happen without showing the dialog again.    This enabled seamless manual saving (via "save changes" menu item) and autosaving while editing (after a set number of keystrokes) as well as autosaving on a timed basis.

Unfortunately, this method of gaining permission for file I/O was prone to some hacking.  There were ways of spoofing the dialog... for example, by having it appear off-screen and showing an alternative on-screen message box with a simple OK button to trick the user into giving permission to access the file system without realizing it.

In addition, once permission was granted, access to the file system was *unrestricted*.  You could navigate to ANY folder, programmatically, and read/write the directory and file contents at will from within TiddlyWiki.  Of course, this presented a HUGE security hole, since tiddlers containing embedded inline javascript could be easily copied from remote sources and, if permission to access the file system had *ever* been granted, then file I/O could occur silently, without requiring any user interaction or even awareness that file I/O was taking place.

Of course, TiddlyWiki also benefited immensely from this ability, as it allowed the kind of smooth, "just save it" behavior that most people have come to expect from an application, as well as the ability to provide plugins to provide more sophisticated file-related interactions, such as Import, Export, and SaveAs and automatic backup strategies that used timestamps in filenames to preserve previous revisions on minute, hour, daily, and weekly basis.

Inevitably, however, the browser makers came to the conclusion that file I/O was too dangerous to be allowed directly from insecure Javascript, and they attempted to limit the impact by restricting file I/O to "the current working folder and below" and then gradually phased out and then completely removed support for access to "privileged I/O functions" except when they are defined as part of curated browser-based addon code that must be explicitly installed on each platform and instance of the browser that you intend to use with TiddlyWiki... and thus, gave rise to clever bits of code like TiddlyFox and TiddlyDesktop.

When Jeremy began work on TiddlyWiki5, one of the major advances in architecture that he innovated is the use of FileSaver modules.  This allows a much more consistent internal API for TiddlyWiki to work in a variety of environments and configurations, including stand-alone files, locally-served folders (via nodejs), remotely-hosted stand-alone files (via upload to store.php... e.g., TiddlySpot.com), and full server-side hosting.

Independent of these core-included abilities, other people in the TW community have created FileSaver modules for using various databases (either locally-hosted or remote).  There's also browser-based LocalStorage I/O... which uses a "sandboxed" private file space that is allocated within the browser's local cache, without exposing the rest of the file system.

Regrettably, all of these solutions, regardless of their benefits also have their peculiarities and drawbacks, including platform, environment, and browser-specific limitations as well as various multi-step installation/configuration issues.

Currently, there is only ONE file I/O method included in the TW5 core code that can be considered to have ANY chance of being "universal"... and that is the so-called "fallback download saver" method.   Every browser that permits downloading a file provides some kind of secure, interactive process to allow the user to transfer files onto their local file system while reducing the risk of being struck by some kind of malicious exploit.

So... this leads to  back to your statement that I quoted above:

The fallback behaviour of save(1) save(2) is not viable, IMO, for most folk. 

To which I respond: I respectfully disagree... and here's why:

First, the "download a file" behavior is already familiar to nearly all users.  Sure, there are some system-specific differences between the various browsers and platforms, but for the most part, they all work nearly the same way when a download is initiated.

For example, some browsers will immediately ask for a 'destination folder' for the download, but others are configured by default to simply place downloaded content into a "Downloads" folder, without asking the user.  Most browsers allow the user to change this setting so that downloads will always request a destination folder. IMO, the effort to change this setting is MUCH less than that required to install and configure a browser-specific addon.

Second, once the browser has been configured to ask for a location, the automatic "collision handling" of save(1), save(2), etc. can actually be a HUGE benefit to TiddlyWiki's "edit-save-reload" workflow cycle.  For example, consider the following workflow scenario (that I actually use myself)

1) go to a folder on my desktop that contains "index.html" and open it to start working

2) make some changes that you want to keep and press "save changes"

3) browser download dialog appears.  If needed, navigate to the "current working folder" (the one containing index.html)

4) the default suggested filename should be something like "index (1).html"

5) press save and resume working on the current document without reloading

6) repeat as desired, creating incremental "checkpoint" saves "index (2).html", "index (3).html", etc.

Then... suppose that as you continue to work, you realize that you "messed something up", and can't figure out what broke.  So, you go back to the folder on your desktop, and open the most recent "checkpoint" save and see if the problem existed in the previous revision.  If it did, then you keep working backwards, until the bug disappears.  Then, you can carefully compare the two revisions to determine exactly what changed, and hopefully find the error quickly.

This "checkpoint" revision methodology also lends itself to making small experimental changes without immediately committing those changes by always overwriting the base "index.html".  This is especially useful if the changes require a reload of the TiddlyWiki to be tested.  After saving to index(1).html, just load that saved file in another browser tab or window.. If it fails to load, or otherwise has some bad bug that make it inoperable, you still have the current index.html loaded in the first tab, so you can go back and fix things there.

7) if you are satisfied that all changes are good, save again (from either tab)... and select the base "index.html" file as the destination

8) when the system asks, confirm "replace this file" (or "allow overwrite".. .or whatever the wording is)

9) continue working (with or without reloading)

10) finally, when you are completely finished with your work session, you can go back to the folder on your desktop and delete all the checkpoint files, leaving just the final updated base "index.html"... just as you would expect.

Personally, I quite like the 'safety' provided by the automatic addition of "(n)" to the filenames.  It ensure that I don't accidentally overwrite the base file without a deliberate decision that I am ready to make my changes permanent.  It also makes hunting for bugs easier since I can use external tools (e.g., "diff") to compare the saved files and quickly find all the differences.

One last interesting scenario.... sometimes, especially when researching the answer to a question posted online, I will open http://tiddlywiki.com/empty.html, and start creating a few test/example tiddlers from scratch.  Once I have a good working example, I can just use "save changes" to trigger the usual download saver, which provides *exactly* the same local file saving experience to me, regardless of whether I am working online or locally.

In conclusion:

While solutions like TiddlyFox and TiddlyDesktop do provide a 'smoother' process for local file saving and we should clearly continue efforts to implement a wide variety of FileSaver modules and other file-saving solutions, the "fallback download saver" process is actually quite useful and remarkably consistent and reliable across nearly all platforms and does not require ANY extra steps to install/configure, making it the likely experience for most 'novice' TiddlyWiki users.

IMO, the best strategy for assisting novice users with the file saving experience is to first help them to understand the default download saving process while also introducing them to the more advanced solutions provided by various plugins, addons, and external apps.

your thoughts?

-e

Eric Shulman

TiddlyTools: "Small Tools for Big Ideas" (tm)

InsideTiddlyWiki: The Missing Manuals

[tejjyid]

I develop my TW code inline; currently from a file, as there's a lot to do handling the upgrade to TW5, but hopefully, in the future, from the browser again. I would routinely save & reload a TW tens, and possibly hundreds of times in a coding session. This is going to be an much more unpleasant experience if I have to go back to the filesystem to open a new file after every save, as well as delete the large number of old and dysfunctional copies of the file which might be dangerous to leave around.

My yimao.

Andrew.

[Eric Shulman]

On Monday, March 13, 2017 at 9:08:25 PM UTC-7, tejjyid wrote:

I develop my TW code inline; currently from a file, as there's a lot to do handling the upgrade to TW5, but hopefully, in the future, from the browser again. I would routinely save & reload a TW tens, and possibly hundreds of times in a coding session. This is going to be an much more unpleasant experience if I have to go back to the filesystem to open a new file after every save, as well as delete the large number of old and dysfunctional copies of the file which might be dangerous to leave around.

Your workflow always overwrites the index.html "tens, and possibly hundreds" of times in a coding session.  If that's how you prefer to work, that's fine by me. 

However, it's a bit like walking the high-wire without a net: if something you just wrote causes a fatal error at load time (the dreaded RSOD), correcting those changes could be very problematic, since you aren't keeping backups along the way.  Depending upon how much is changed with each save, it might be a real headache to isolate the source of the fatal error without having a nice "diff" of those changes to compare.

However... even with my suggested "download saver" workflow, you can achieve the exact same "high-wire" results simply by always selecting the base index.html to overwrite each time rather than creating additional numbered 'checkpoint' saves.

Of course, this *does* add two actions to your existing workflow: a double-click to select the "index.html" filename in the list and a single-click to confirm the "are you sure?" popup, but I feel that this adds a very minor inconvenience at worst, and provides a valuable 'sanity check' before actually committing to a non-recoverable overwrite of the primary work file.  

In addition, after you have allowed the overwrite to proceed, the rest of your existing workflow (i.e., reloading the saved file to test and continue working) remains exactly the same: you reload the current document simply by pressing the browser's reload command (ctrl-R or alt-f5 in Chrome).  There is absolutely no need to "go back to the filesystem" after ever save and, since you aren't actually creating 'checkpoint' saves, there are also no "old and dysfunctional" copies to clean up afterward.

Also note that if you DO choose to create 'checkpoint' saves along the way, you still usually don't have to go back to the filesystem to open them, since many browsers provide some kind "download status bar" output that includes a button to quickly open the newly saved file with just one click.  Sure, you have to remember to clean out the left-over checkpoint files at the end of your work session, but it is typically a very easy operation to select the unwanted files (i.e., using shift-click to select the whole set at once) and then pressing 'delete' (or dragging to the trash)... and if you're using a command line environment (i.e., a Linux shell), then it's even easier to clear out the files with just a single "rm index*(*).html" command

enjoy,

[@TiddlyTweeter]

Thank you Eric for taking the time to thoughtfully lay out the detailed history. I really appreciate it.

By way of reply I'd like to divide between two things. Its just a way of talking, though perhaps brings a bit from a slightly different perspective. Two broad points ...

1 - INNOCENT LANDING.

2 - PEOPLE WHO SHOULD BE WISER ALREADY

I'd like to start with (2). BACKUP is essential whatever you are doing. Depending of your level of paranoia / experience of PAST oversight.

This is not really a TW issue.

WHY? Because its a sensible empirical convention that you can't rely on one system to protect you. And browsers are very prone to fuck-ups. EXTERNAL backup is pretty reliable. Personally I do automated redundant backups whenever a TW file is changed. To say again, this is NOT a TW issue.

It's a basic attitude. The need for EXTERNAL backup.

BUT: your approach seems to FOG that up with native saving.

SO I question the added value of YOUR scenario: which is, basically, a via-browser backup system.

I'd RATHER talk about EXTERNAL BACKUP on that rather than what reads like a series of complex EXTRA steps.

On (1). Idiots like me arrive everyday. Used to conventions on saving  on a click. I think this is maybe my big point. Its an entirely different one than (2). On this issue it seems that "we" may need to "educate" "them"?

My question on this is this is simply whether its a viable approach to even entertain file save? Jeremy in his note #2 in the starting post seems to incline to on-line services as the easiest way forward for "the masses".

I'm convinced I'm slightly incoherent on all this. Lets stab in the dark together.

Best wishes
Josiah

[Eric Shulman]

On Tuesday, March 14, 2017 at 11:47:45 AM UTC-7, @TiddlyTweeter wrote:

BUT: your approach seems to FOG that up with native saving.

I'd RATHER talk about EXTERNAL BACKUP on that rather than what reads like a series of complex EXTRA steps.

It's clear what you'd "rather" talk about.  But in the process, you are summarily dismissing "download saving" as being "complex extra steps" when they are NOT complex, and the "extra" steps are minimal.  To re-iterate... here's the steps to using the download saver:

   1) click save

   2) double-click index.html (from system-standard "file save" dialog box)

   3) click OK (a simple modal "are you sure" confirmation popup)

   4) press F5

...and out of these 4 ***exceedingly** simple steps, TWO of them (steps 1 and 4) are *exactly* the same as when using TiddlyFox or other 'saver' addons.

And, if we factor in the "complexity" of installation... external backup solutions require researching, choosing, downloading, installing and configuring some variety of backup software that is typically either a completely separate stand-alone application (yet another thing to learn!), or injects itself into the operating system to "automagically" back up changes.  Sure, within your own usage paradigm, browser add-ons (TiddlyFox) combined external backup systems might produce the best workflow for YOU... but for many, many people, installing add-ons and 3rd-party software can be beyond their abilities, or may even be completely prohibited by their work environment.

By comparison, enabling "always ask for location to download" is a simple settings change to an application that is already installed (the browser).  Just to be clear... here's ALL the steps required for the ONE-TIME configuration of the download saver solution.  (note: I use Chrome)

1) select browser command menu (upper right corner, 3-dots icon)

2) select Settings

3) scroll down to the bottom

4) select "advanced settings"

5) scroll down to "download" section

6) check "ask where to save each file before downloading"

DONE.

So... to summarize the complete impact of using the download saver:

* configuration: change one setting in your browser

* usage: adds a double-click and a single-click

oh.. and one more thing... what happens to your external backup strategy when you start traveling with your TW documents and need to use someone else's system to make some changes to your files?  They may not have ANY external backup software installed and, even if they do, in might not be anything like what you are using on your system, and would you really want YOUR files backed up in THEIR system?  Once you leave their home/office, you won't have access to those backups anyway, and might be leaving behind data you didn't intend to share.... and let's not even consider the issues with using public internet cafe's.

With download saving and a USB stick, you have a nearly 100% portable solution that allows you to work with virtually ANY browser you may encounter, with NO dependencies on any other applications and no data left behind.

-e

[A M Alfaro]

Hi Josiah,

I might be an even more naïve user than yourself. I think it's safe to say that the basic users of the world really don't think about making backups of anything. At all. Ever. No matter how many, many, many times they are told to do so. Just me speaking from the pov of being the most tech-savvy person in my family. And one of the things I loved about TWClassic is that it did that backup thing for you. So on the one hand, yeah, it isn't necessarily a TW thing, but on the other it is because it originally had that functionality built in and there's an expectation for it to continue.

I myself drifted away from TW during that period of not being able to easily save via the browser and came back once TiddlyFox was available. I use TW at work for project management, and need it to be easy to save. I don't care how that is implemented. I've changed jobs and now only have IE10 for a browser and was really worried I'd have to use Outlook for task management (XP). I also don't have the ability to update anything without Admin permission, so installing the IE tiddly addon felt like a huge win, but I still get the save as dialog every so often. An approach like Eric's is great for me (and one I hadn't thought of because I generally hate that "(n)" thing). Also, because of TWClassic, I'm already used to deleting extraneous files from my TW folders. That little backup folder could get pretty full pretty quickly.

At the end of the day, I don't think the smoothness of saving is what's going to keep TW from spreading to the masses. It's the documentation and the learning curve. I kept away from TW5 because the $:\ notation seemed so foreign to me at first. Then I got this job with no FireFox and was forced to engage TW5. I was getting to know it via Cardo when IT updated my system and broke it. I'm not sure why now but all I get on Cardo is the RSOD, but I could still use vanilla TW5. This probably wasn't the best way to approach learning, but now I'm building my own method of task management as I go. The thing is I know none of my family and very few of my friends would want to invest the time needed to learn TW and the multiple languages associated with it. They would take one look at the editor UI when making their first tiddler and would peace out. But then I don't think they're Jeremy's audience anyway. This a creative tool for creative people who enjoy tinkering. IMO anyway.

All of this is leading to my opinion that the simplest way to save should probably be the only way to save and it's up to the user to make those backups as with every doc on their computer. One button saving with backups was nice, but I think it's time we let it go.

Peace,

Anita

[Ákos Szederjei]

TiddlyFox, like TW Desktop, saved the TW file whenever a Tiddler was closed. So
no dialog vs. 4 step. Any dialog causes more complexity.

Why have word processors / text editors auto safe feature? Because they are
convenient and speed up work.

You can always safe with File / Save As in the browser. 4 Steps too.

Both Linux and Windows have backup tools which are quite good. They take 30
seconds to setup and done.

I understand the technical difficulties, and it is ok not being able to resolve
it, or even not wanting too, because other feature are deemed more important.
But please, do not tell me that without TiddlyFox my workflow is comparably
easy. It is not obviously not.

Ákos

[Eric Shulman]

On Tuesday, March 14, 2017 at 3:35:46 PM UTC-7, Ákos Szederjei wrote:

I understand the technical difficulties, and it is ok not being able to resolve 

it, or even not wanting too, because other feature are deemed more important.

It's ok to disagree with what I wrote... but...

I never said ANYTHING about "not wanting to" or "deemed more important"

DO NOT PUT WORDS IN MY MOUTH!!!

Just because you don't agree with my explanation does not mean you get to MAKE STUFF UP about what I said.

YOU ARE NOT DONALD TRUMP!

[Ákos Szederjei]

Dear Eric!

Who said YOU are not being able to resolve it, or YOU do not want too, because
other feature are deemed more important? Really...
The world is not revolving around you. This list is about TW and not about
your capabilities. What you do or want I could care less. It is not that you
will resolve the issue of the plug in on your own. If you are the sole
developer of this issue I profoundly apologise.

Talking about making stuff up? You claimed that the 4 step solution of yours
is the same as if the plug in is used. Really? I just closed a Tiddly in old
FF and it auto saved. The same, sure, and my microwaves make video
recordings...

Fortunately, I am not really dependent on the offline functionality for my wiki.
Your argumentation (or the lack of it) convinced me to switch now to another
wiki and not wait for a solution for TW' saving problem.

Good luck with your endeavour!

Ákos

[Mat]

Guys, guys, please keep it constructive. It is super easy to misunderstand - and to misphrase - in this text discussion format. The real efforts are towards the betterment of TW, which is difficult enough per se ;-)

Hopefully this idea/question can put focus back:

How about bookmarklets? Could there be a bookmarklet save button that both has access rights to the page and to the local computer?

Thank you!

<:-)

[PMario]

On Wednesday, March 15, 2017 at 10:31:16 AM UTC+1, Mat wrote:

Guys, guys, please keep it constructive. It is super easy to misunderstand - and to misphrase - in this text discussion format. The real efforts are towards the betterment of TW, which is difficult enough per se ;-)

Well said.
 

How about bookmarklets? Could there be a bookmarklet save button that both has access rights to the page and to the local computer?

The same javascript restrictions as for pages, apply to bookmarks.

-m

[Jeremy Ruston]

Hello Everyone,

It’s a shame to see this thread go a little off the rails as this is an important and interesting discussion — which may be why it has aroused such passions. That passion is itself an important component of the TiddlyWiki community: for many of us, using and working on TiddlyWiki is deeply intertwined with our lives, and so it’s natural to have strongly held opinions about it.

Nonetheless, we all have to pay attention to how we behave in order to keep things civil and fun. That means that we criticise ideas, not people; that we start with the assumption that everyone is participating in good faith, and we understand that the ambiguities and exigencies of online communication can have inadvertent side effects.

We should never lose sight of what we have in common. This community is a living example of how an incredibly diverse group of people can come together and help one another.

Best wishes

Jeremy

> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
> To post to this group, send email to tiddl...@googlegroups.com.
> Visit this group at https://groups.google.com/group/tiddlywiki.
> To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2546852.q7A4t5DQJh%40michael-pc.
> For more options, visit https://groups.google.com/d/optout.

[@TiddlyTweeter]

Ciao Jeremy, Pmario, Mat & others ...

Thanks for pointing out the drift in the wrong direction. I agree its not terribly constructive.

My apologies to Eric if I came over as aggressive. 

I think my point is actually a broader one that I will try to present in a later post.

By way of thoughts on this: The file-saving issues that me and others have presented quite passionately matter, I think, still. BUT they need contextualing in my opinion lest it looks like a conflict over ONE point. It isn't really. And the useful context is Jeremy's second statement.

It is THAT, more than anything, that interested me personally to try and open up more.

Very best wishes to all
Josiah

[Jon]

Excellent.

Regards

Jon

[@TiddlyTweeter]

Ciao all ...

The starting post for this thread came from a private discussion that Jeremy Ruston and I had on Twitter. We both realised it would likely be more productive in public ...

Central to it is this by Jeremy in response to my queries...

Here’s the thing: all the difficulties in getting started with TiddlyWiki stem from the single file architecture.

It’s fiddly and unfamiliar to most people.

The simple fix is to move it to an online service, when all those problems melt away. Simple.

If on the other hand, anyone wants the considerable advantages of working offline without a server, well, then TiddlyWiki is the only thing on the planet that can help them,

and it comes with a learning curve.  (Layout edited slightly by me)

There is a hell of a lot of his experience and knowledge packed into that one paragraph. Its almost a roadmap to the future too??

Its the implications of this vision (as well, I guess, its accuracy) that I think is worthy of much attention.

Best wishes
Josiah

[Arlen Beiler]

What if we would combine the best of both words?

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscribe@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f64623ef-ab8c-4cb9-ac65-cba804474888%40googlegroups.com.

[Arlen Beiler]

I'm thinking of a simple one file store.js file that would allow you to load any TiddlyWiki from the folder you are serving and it would post the changes back to the server.

node.exe store.js /path/to/my/folder

Navigate to http://127.0.0.1 and it will show you a standard directory listing allowing you to select which tiddlywiki you want. 

It could load the tiddlywiki directly or in an iframe and then save changes back to the server.

[Arlen Beiler]

Any thoughts?

[Arlen Beiler]

Are you allowed to use portable apps? I am thinking of something that would not require installation.

On Wed, Mar 15, 2017 at 12:44 PM, Lost Admin <thelos...@gmail.com> wrote:

The challenge with any solution that involves more than using a web browser is that some of us won't be able to use it. I suspect this group is a small sub-set of TiddlyWiki users, so your idea still has merit and, I think, should be pursued.

I use TiddyWiki at work because most of the information sources and tools I need to look things up are on slow sharepoint sites (is there such a thing as a fast sharepoint?). So, I copy the stuff I need from sharepoint into a local TiddlyWiki.

I'm technically savvy enough to confidently install node.js on my work computer but I'm not allowed to. I shouldn't even be able to except I need escalated privileges for one of the tasks I have to do. But, the company's desktop IDS would catch if I installed node.js without permission (which I won't get). Fortunately, add-ins for Chrome are allowed (and they haven't updated Chrome yet, so it still works). Sadly, I'm not allowed Firefox (I don't know why).

When they update Chrome, I will need to switch how I use TiddyWiki and have a slew of index(n).html files to sort through.

At home, I don't have this problem. I have a small server (Intel NUC) that provides me with a tiddlywiki server (apache, php, and store.php). But, the average non-technical user wouldn't be able to do that.

On Wednesday, March 15, 2017 at 10:53:57 AM UTC-4, Arlen Beiler wrote:

I'm thinking of a simple one file store.js file that would allow you to load any TiddlyWiki from the folder you are serving and it would post the changes back to the server.

node.exe store.js /path/to/my/folder

Navigate to http://127.0.0.1 and it will show you a standard directory listing allowing you to select which tiddlywiki you want. 

It could load the tiddlywiki directly or in an iframe and then save changes back to the server.

On Wed, Mar 15, 2017 at 10:50 AM, Arlen Beiler <arle...@gmail.com> wrote:

What if we would combine the best of both words?

On Wed, Mar 15, 2017 at 10:48 AM, @TiddlyTweeter <tiddly...@assays.tv> wrote:

Ciao all ...

The starting post for this thread came from a private discussion that Jeremy Ruston and I had on Twitter. We both realised it would likely be more productive in public ...

Central to it is this by Jeremy in response to my queries...

Here’s the thing: all the difficulties in getting started with TiddlyWiki stem from the single file architecture.

It’s fiddly and unfamiliar to most people.

The simple fix is to move it to an online service, when all those problems melt away. Simple.

If on the other hand, anyone wants the considerable advantages of working offline without a server, well, then TiddlyWiki is the only thing on the planet that can help them,

and it comes with a learning curve.  (Layout edited slightly by me)

There is a hell of a lot of his experience and knowledge packed into that one paragraph. Its almost a roadmap to the future too??

Its the implications of this vision (as well, I guess, its accuracy) that I think is worthy of much attention.

Best wishes
Josiah

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f64623ef-ab8c-4cb9-ac65-cba804474888%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/d34a6877-73e7-4ad3-9086-42edcea0b795%40googlegroups.com.

[Lost Admin]

I don't actually know. I am allowed to use USB thumb drives, though. So it is something to think about.

[tejjyid]

I'll try again, but my posts keep getting deleted...if anyone can help me that it'd be appreciated...

I don't think it's right to characterise the problems as being with the single file architecture, because I don't really see TW as a single file architecture, any more than Excel. TW is a program and a data file, as is Excel. The difference is that the program for TW is called the browser. We think about the TW program as being that part of the data in the file that gets executed, but that's really analogous to VBA code. 

Program                                                               - File
Excel
       Application functions
       Enables VBA                                                    - user code (VBA, formulas); data
       File IO
Browser
       Enables JS                                                     - application functions (JS, macros, widgets); user code (ditto); data
       ?FIle IO?

  

The problem occurs because the TW driving program, the browser, is not longer fit for purpose. If Excel stopped saving spreadsheets, that'd obviously be a pretty major disaster. TW, though, doesn't control the browser, so we have to take our lumps when it does stop saving.

I switched to using Firefox for TW (from Chrome) because of the extension which allowed overwrite saves. The save(n+1) option is rubbish; I mean it's doable, obviously, but it is not convenient. It's not a user-winning experience. If that goes, I guess I'll switch to using Tiddlyfox, which seems to be OK. It's the program TW controls which can run TW and also save. It's a pity to lose the "elegance" of running with a program that is already readily available, but in terms of offline user experience , downloading a program, installing it and running it is not a big challenge for most people. 

I think the future will be TFox for standalone; browser for online; Node for the minority; offline browser for the rest, and I don't really see a problem with that. It's more user-friendly, IMO, than running TW on top of a database. No matter how hard people work to make the underlying technology transparent, I think the extra complexity will eventually show up. I don't think that's the right place to invest the technical talent.

Cheers, Andrew

[A M Alfaro]

Arlen,

I'm a part of the minority which cannot use USB sticks at work. Security recognizes and blocks flash drives. The more restrictive my environment becomes, the more I dread the day I can't even get TW at work. I tired to email a copy of my project management wiki to myself at home and it was blocked based on content and file size. I imagine one day I won't be able to email myself an empty wiki from home to work, which is what I did to get it last month. I could get to the website but couldn't download an empty copy.

---

Andrew,

I think I get the analogy you're trying to make, but I believe the premise is slightly off because Excel is a complete package, meaning it's designed from top to bottom for all "parts" to work together. Tiddlywiki and the browsers are not designed that way. The only way to solve that would be for Jeremy to repackage the single file application as that "Excel"-type of program. I don't know anything about the JSON side of TW, so it could be that it provides this type of solution (?).

Also for clarification, TiddlyFox is just a FireFox addon that smooths the user's saving experience. It isn't a tool being manipulated by TW which seems to be how you're describing it. In fact, what you're describing as the future of TW is already in trouble and continues to be TW's recurring problem. Browser security continues to evolve in ways that close off the function TW needs to smoothly save over itself. That elegance is at the mercy of the browser developers.

----

I completely get that mine is an unpopular opinion but I'm not seeing any way around it: Jeremy's fallback measure of using the Save dialog will become the only available way of saving TW in the future. I don't think of it as inelegant; I think TW users just aren't used to it and are loathe to accept it. Like I said before, we got used to a different experience. We have the expectation of it. Maybe it's time we reset our expectations on this one thing? Is it truly so disruptive to the user experience? I don't think so.

From my point of view, it's actually much easier now that TW "falls back" to the Save dialog.

Peace,

Anita

[@TiddlyTweeter]

Ciao Arlen & all

Arlen Beiler wrote:

What if we would combine the best of both words?

I do think that is something in all this. Perhaps it is not, as you suggest, so cut and dry?

Personally I am very interested in Danielo's ongoing project of a TW that can auto-save into Browser Storage (into an automatically created local database), rather than using the Download Saver mechanisms.  It can also be synced with a remote database. Once that is done you can use it from more than one location. Basic info here: https://noteself.github.io/

I haven't had time, nor have I the competence, to thoroughly test it, but I think it is very suggestive to see something concrete like that actually seems to work.

Its in some ways, potentially, a demonstration of how the "on-line" and "off-line" can be crossed. I think its interesting to look at in the context of Jeremy's comments.

Best wishes
Josiah

[Mat]

I could swear someone posted a link above to some Chrome extension.. or at least mentioned on, but since I can't find it;

Downloads Overwrite Already Existing File and on github  - a quick glance at the code gives the impression of something extremely lightweight!


<:-)

[Mat]

Possibly also of interest: Downloads Router Chrome Extension to (perhaps) always have TW files go to a designated local folder.

<:-)

[Danielo Rodríguez]

Thank you Josiah for mentioning NoteSelf.
I'm not sure why most people ignore it or have decided to not talk about it.

It has all the three ootions: autosave on your local browser , manual download option and automatic synchronization to a remote databases.

I use it daily both at my work and my mobile phone. On my work I use it on chrome, while on my mobile phone I use the Android app (available on this forum ) and I never had a problem . I never had to remember which one was my latest version , I never had to wait until Dropbox synchronizes it to my new location , I never had to melt two files searching for the most recent editions of each. None of those problems , and you have a seamless experience both on mobile and desktop browsers. You don't even need to install the Android app if you don't want, the online version provides also an app-like experience .

As I said several times, I have created this for myself, but after a while I realized that maybe others could benefit from it so I have released. It's sad that so few people is using it .

[Lost Admin]

I posted the link. It turns out it stopped working on current versions of Chrome because Google altered functionality for security reasons. I'm using an older version of Chrome (because my employer hasn't upgraded yet, so it works for me).

The link is https://github.com/Arlen22/tiddly-chrome-app

NOTE: I'm not the author, just a user.

[Lost Admin]

I looked at it. It looks interesting. I liked the idea. I couldn't find any instructions on how to set-up my own server to host my own.

[Danielo Rodríguez]

El viernes, 17 de marzo de 2017, 15:16:50 (UTC+1), Lost Admin escribió:

I looked at it. It looks interesting. I liked the idea. I couldn't find any instructions on how to set-up my own server to host my own.

I want to add subtitles and some voice explanations, and add it to the main page, but here is a 2 min video with a small  how-to

https://youtu.be/Oc5lNND8dZE 

[Mat]

@Danielo

I'm not sure why most people ignore it or have decided to not talk about it.

I agree it deserves a LOT more attention, not least on the boards. (I'll try to plug NoteSelf when it is relevant. ;-)

As for using it, I can't talk for others but the FAQ reads:

[...]Can I use for production/very important things?

I would love to answer yes, but for now please don't do it. Noteself is still on Beta stage, and [...]

So, basically, I don't dare to put my important stuff there and the non-important stuff... well, I find tiddlyspot really convenient and the saving works great. And when I do my experimenting, chances are I'll eventually publish it and then it's already there.

@everyone
Now, it would be very useful if we could choose saver for download #1755 so people more easily could easily try out various solutions considering that many people are now working alternatives for saving or hosting, I think it would make sense to prioritize this issue. A later step might be to mesh it with the export function, e.g so people can save static tids to a blog.


<:-)

[Arlen Beiler]

Lost admin, 

Do you mean that TiddlyChrome app isn't working or were you talking about the download router?

Thanks,

-Arlen

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3b315ab3-69c9-4ef4-9e66-3bfb676f7458%40googlegroups.com.

[tejjyid]

On Friday, 17 March 2017 03:14:39 UTC+11, A M Alfaro wrote:

Arlen,

I'm a part of the minority which cannot use USB sticks at work. Security recognizes and blocks flash drives. The more restrictive my environment becomes, the more I dread the day I can't even get TW at work. I tired to email a copy of my project management wiki to myself at home and it was blocked based on content and file size. I imagine one day I won't be able to email myself an empty wiki from home to work, which is what I did to get it last month. I could get to the website but couldn't download an empty copy.

---

And

I think I get the analogy you're trying to make, but I believe the premise is slightly off because Excel is a complete package, meaning it's designed from top to bottom for all "parts" to work together. Tiddlywiki and the browsers are not designed that way. The only way to solve that would be for Jeremy to repackage the single file application as that "Excel"-type of program. I don't know anything about the JSON side of TW, so it could be that it provides this type of solution (?).

No - I haven't expressed myself clearly, but I think we actually agree. The problem is that TW *isn't* a single-file architecture. It needs other programs to support it, not just an OS. and now, increasingly those programs don't. So I think the problem is deep.  

Also for clarification, TiddlyFox is just a FireFox addon that smooths the user's saving experience. It isn't a tool being manipulated by TW which seems to be how you're describing it. In fact, what you're describing as the future of TW is already in trouble and continues to be TW's recurring problem. Browser security continues to evolve in ways that close off the function TW needs to smoothly save over itself. That elegance is at the mercy of the browser developers.

My bad - I was thinking TiddlyDesk, but my fingers were thinking something else. IMO TiddlyDesk is the only future of the so-called single-file TW.

[@TiddlyTweeter]

Ciao tejjid and all ...

On Monday, tejjyid wrote:

... The problem is that TW *isn't* a single-file architecture. It needs other programs to support it, not just an OS. and now, increasingly those programs don't. So I think the problem is deep. 

 I agree, in the sense that the mechanics of HOW you get TW to run/work do matter.

Much of Jeremy's second statement, I keep referring to, implies that, I think. He posits differential ways forward though. NOT one model (*I* think).

That "contradiction" (is it?) between "self-contained" V. dependence on a "run environment" for use is interesting ... ? I'm not so sure that obviates "single-file architecture" per se.

Best wishes
Josiah

[@TiddlyTweeter]

I would like to add to this discussion this ...

On Sunday, 5 March 2017 09:38:00 UTC+1, Jeremy Ruston wrote:

Overall, I’d like to see TiddlyWiki better serve the needs of multiple audiences:

* commercial services for general users

* easy Node.js app deployment for advanced DIY users

* continued support for the standalone configuration in the browser for most DIY users

[Jed Carty]

As far as the easy deployment of node.js apps goes, I am working on making a control interface and data dashboard for my robot using tiddlywiki. The robot runs in node so I have the same script running both tiddlywiki and the robot. I set up bi-directional communication between the robot and the browser. I am trying to make everything modular and easy to use so I am hoping that it can help with the creation of other applications in the future. My brother has some ideas for using this as a way to make multi-user wikis but we haven't made any significant progress on that side yet.

We are currently polishing the robot code in preparation for releasing it as open source so it isn't available yet, but it hopefully will be soon. I am going to be bringing a tiddlywiki controlled robot up to Oxford for the meet up.

[@TiddlyTweeter]

Jed

This is exactly IT.

Futures understanding.

Josiah, x

[Danielo Rodríguez]

Hello @Mat

 

I agree it deserves a LOT more attention, not least on the boards. (I'll try to plug NoteSelf when it is relevant. ;-)

Thanks!

 

As for using it, I can't talk for others but the FAQ reads:

[...]Can I use for production/very important things?

I would love to answer yes, but for now please don't do it. Noteself is still on Beta stage, and [...]

So, basically, I don't dare to put my important stuff there and the non-important stuff... well, I find tiddlyspot really convenient and the saving works great. And when I do my experimenting, chances are I'll eventually publish it and then it's already there.

That is a disclaimer. As I said, I use it everyday without any problem or data loss. But I don't want anyone to trust it 100% like a comercial product and then come back to me with any inquiry if they mess it up. In any case All the technologies behind NoteSelf are quite mature, PouchDB is a widespread project, TiddlyWiki is on stable stage and CouchDB is a very mature product too.

[@TiddlyTweeter]

Ciao Danielo

I agree with all you write. All the components are mature and work.

WHY is it so difficult to get started?

1 - its unclear how exactly to sign up to Cloudant. And whether they will CHARGE your Credit Card. Do you need to pay to just test?

2 - its unclear what in NoteSelf is the TW "Evernote Replacement" and what could be used other ways.

3 - personally I'm interested in the PouchDB / CouchDB combo for E-pubs but your github does not explain how to integrate the functions of PouchDB in a standard TW that would enable that (not that you SHOULD--only if you interested in that).

4 - I suspect that the PouchDB mechanism could solve a lot of hassle that people have with saving TW. I think it deserves a lot of attention.

Best wishes
Josiah

[Danielo Rodríguez]

Hello Josiah

Very good questions. I think they should be added to the official FAQ. Would you mind to open an issue to the official NoteSelf Repo?

 

1 - its unclear how exactly to sign up to Cloudant. And whether they will CHARGE your Credit Card. Do you need to pay to just test?

Those are two questions actually. About how to sign up to Cloudant, there is a video. I should spend some time making it remarkable. Regarding the second question, Cloudant DO NOT require any Credit Card to sign up, and they will not charge you anything unless you hit some (quite generous) milestones.

 

2 - its unclear what in NoteSelf is the TW "Evernote Replacement" and what could be used other ways.

For me being able to store notes, checklist, bookmarks, all in one place and have them synched between devices is the part that replaces Evernote.

 

3 - personally I'm interested in the PouchDB / CouchDB combo for E-pubs but your github does not explain how to integrate the functions of PouchDB in a standard TW that would enable that (not that you SHOULD--only if you interested in that).

That is because I'm not interested on giving support to standalone usages of TiddlyPouch. They require some technical skills that I don't have time to properly explain to normal users. Any advanced user otherwise should be able to just go to TiddlyPouch repo and grab it to their own needs.

 

Regards

[@TiddlyTweeter]

Ciao Danielo 

Thanks for your response.

On Wednesday, 22 March 2017 12:51:15 UTC+1, Danielo Rodríguez wrote:

Very good questions. I think they should be added to the official FAQ. Would you mind to open an issue to the official NoteSelf Repo?

Sure. If it is helpful.
 

3 - personally I'm interested in the PouchDB / CouchDB combo for E-pubs but your github does not explain how to integrate the functions of PouchDB in a standard TW that would enable that (not that you SHOULD--only if you interested in that).

That is because I'm not interested on giving support to standalone usages of TiddlyPouch. They require some technical skills that I don't have time to properly explain to normal users. Any advanced user otherwise should be able to just go to TiddlyPouch repo and grab it to their own needs.

In the context of the current thread I am very appreciative of your answer. I think its obvious, in a way, that one person following an interest can't easily support carrying forward of their work other than in a very delimited way. They just don't have the time.

But, also, from my point of view it also looks like, in some ways, good things in TW that might well support wide use by non-specialists, get used by a few, and never reach a critical mass. I'm observing this phenomena and thinking about it.

Its amazing the number of WAYS that TW can be got to work. But actually forming an overview of them, one that you could communicate to others, is not so easy.

Just thoughts

Best wishes
Josiah

[Arlen Beiler]

The tiddlywiki architecture is inherently single file. This is why it is so hard to get multi-user configured properly. You would have to virtually dismantle tiddlywiki and put it together differently to get anything as static as Wikipedia. 

Even the server and online versions download everything in few files and the core idea again is one file. If you load a tiddlywiki, the chances are that the entire thing will slowly get loaded as you browse if it was Wikipedia.

There are many options going forward, and almost all of them are very single file oriented when setup correctly.

So I don't think our browser conundrum is going to be too much of a hold up. It will only change the way things work, but they can still work just as fast.

My thoughts,

-Arlen

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/cff0047d-ebf4-4072-97e4-b094190886fe%40googlegroups.com.

[@TiddlyTweeter]

I'd like to add this from another thread. The point on this was about different ways of solving a problem. Jed and I were discussing whether it could be INTERNAL TW or EXTERNAL manipulation of a TW. Jeremy commented. His main point is (I think) its not so much about technique as CONCEPTUALISATION of what TW is. And in a BROAD concept of it comes more freedom.

On Wednesday, 22 March 2017 22:17:16 UTC+1, Jeremy Ruston wrote:

Another way to think about things is that TiddlyWiki lets you fairly seamlessly switch between different perspectives/modalities in using the single HTML file configuration:

* As an web app, experienced through the browser

* As a single, opaque file that can be emailed/Dropboxed/Slacked etc. as a blob

* As a plain text file that can be backed up, edited, etc just like any other text file

* As a fancy ZIP file that can contain multiple items

* As a standalone tool to process content elsewhere, for example to generate a static, secondary representation of content for publication/distribution

While the specific capability to perform bulk operations like search and replace is useful, I think the real value is more conceptual: we can switch between different ways of thinking about TiddlyWiki according to the task we face.

[Jeremy Ruston]

Hi Arlen

The tiddlywiki architecture is inherently single file.

I’d respectfully disagree with that statement.

TiddlyWiki 5 has a chicken and egg architecture: the Node.js configuration is the chicken; the egg that it produces is the standalone single file configuration. But note the relationship: the Node.js configuration creates the single file configuration, not the other way around.

So, the archetypal form of TiddlyWiki is the Node.js configuration.

The key characteristic that is shared by both configurations is the idea of keeping all data in memory (quite a popular architecture in this decade). But that’s something that can be changed: the store is pluggable and can be replaced.

This is why it is so hard to get multi-user configured properly. You would have to virtually dismantle tiddlywiki and put it together differently to get anything as static as Wikipedia. 

That sounds like a non-sequitor. There are a number of missing pieces for the multi user configuration where TW runs in the browser, as have been acknowledged and listed elsewhere. You seem to be referencing the architecture whereby individual static pages are generated (rather than shipping a full TW to the browser). I’m not aware of any major omissions there.

Even the server and online versions download everything in few files and the core idea again is one file.

I think here you are referring to the configuration where the server serves a full TW HTML file to the browser. That’s not the only configuration that is supported.

If you load a tiddlywiki, the chances are that the entire thing will slowly get loaded as you browse if it was Wikipedia.

Here I think you’re talking about lazy loading?

I don’t understand the comparison to Mediawiki. TiddlyWiki doesn’t have the same goals as MediaWiki. Why would it? We already have MediaWiki, so I’m not interested in re-inventing it. TiddlyWiki is trying to do something different.

There are many options going forward, and almost all of them are very single file oriented when setup correctly.

I don’t quite understand why you think that “almost all of them are very single file oriented”?

So I don't think our browser conundrum is going to be too much of a hold up. It will only change the way things work, but they can still work just as fast.

I think we’re coming from the same place here: the plethora of different configurations that TiddlyWiki supports means that we can be confident that it can be adapted to keep working into the far future.

Best wishes

Jeremy.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSTOKu6KpTqaYj-CoZZ9Ap%3Du8yKyfGAaGqt19fSrwOwq8Q%40mail.gmail.com.

[Arlen Beiler]

Hi Jeremy, 

It sounds like I didn't come across very clearly. I apologise. Hopefully this will help clarify.

Even the server and online versions download everything in few files and the core idea again is one file.

I think here you are referring to the configuration where the server serves a full TW HTML file to the browser. That’s not the only configuration that is supported.

I was actually referring to noteself and TW5 in the sky as well. Tank would be an exception. Perhaps I should look that one up again.

I don’t understand the comparison to Mediawiki. TiddlyWiki doesn’t have the same goals as MediaWiki. Why would it? We already have MediaWiki, so I’m not interested in re-inventing it. TiddlyWiki is trying to do something different.

I'm comparing it to MediaWiki because that is what I know. I would like to find a way to implement multi-user. Maybe I should broaden my horizons :)

So I don't think our browser conundrum is going to be too much of a hold up. It will only change the way things work, but they can still work just as fast.

I think we’re coming from the same place here: the plethora of different configurations that TiddlyWiki supports means that we can be confident that it can be adapted to keep working into the far future.

That was actually the thrust of the entire email. Obviously it didn't come across very clearly. My apologies :)

I was basically trying to say that is is very single file oriented (whereas MediaWiki is very database oriented) therefore it is easy to switch platforms (browsers themselves aren't going anywhere). Anything can serve one file -- especially one that can generate itself.

The NodeJS system can generate almost anything. So between those two we should be good.

Best wishes to you too :) I appreciate all the effort you've put into Tiddlywiki :)

[David Szego]

Naieve but stupidly simple potential solution...

What if one of the Core Tiddlers was a Java web server running on localhost, which the rest of the Core sync'd to?

Wouldn't that local Java web server have access to write files?

https://github.com/NanoHttpd/nanohttpd

• Only one Java file, providing HTTP 1.1 support.
• Supports file upload. Uses memory for small uploads, temp files for large ones.

or

http://stackoverflow.com/questions/3732109/simple-http-server-in-java-using-only-java-se-api

[Jeremy Ruston]

Hi David

Naieve but stupidly simple potential solution...

What if one of the Core Tiddlers was a Java web server running on localhost, which the rest of the Core sync'd to?

Wouldn't that local Java web server have access to write files?

Substitute “JavaScript” for “Java” and that’s a pretty good description of TiddlyWiki running today under Node.js :)

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/df24729e-88de-4e14-b018-d35499b7eb9c%40googlegroups.com.

[David Szego]

On Friday, 24 March 2017 11:24:54 UTC-4, Jeremy Ruston wrote:

Substitute “JavaScript” for “Java” and that’s a pretty good description of TiddlyWiki running today under Node.js :)

Understood, but to avoid the pain / inability to have every user install Node everywhere they want TW, couldn't an embedded Java server do the same thing, and remain self-contained?

[Jed Carty]

The problem is that the single file version runs in the browser context and that prevents it from accessing the file system, you need something to bridge that which is what node does. Anything that is supposed to solve the same problem would have to be external to the browser and would have the same issues as node.

[@TiddlyTweeter]

Having sat with this discussion a few days I'd like to ask ...

   Where are the commercial services?

Best wishes
Josiah

@Jermolene wrote:
* commercial services for general users

[Mat]

   Where are the commercial services?

Commercial services using TW? Or TW-hackers offering services to help out with TW matters? Maybe even Where are all the service people who're supposed to be making TW commercials? ;-) ;-)

<:-)

[@TiddlyTweeter]

Ciao Mat

In the sense that Mr Ruston means.

Josiah

[Lost Admin]

I am also a bit confused by the term commercial services. Both in where they are and what Jeremy meant. Is tiddlyspot a "commercial service"? It's a great service, but I think it's more community than commercial in that from what I can tell, TiddlySpot is provided by community members for the community.

 

[@TiddlyTweeter]

Ciao LostAdmin & all ...

I think its worth coming back to what the initial post in this thread was about...

I think Jeremy's central point (he originally made to me privately on Twitter) was this ...

Here’s the thing: all the difficulties in getting started with TiddlyWiki stem from the single file architecture. It’s fiddly and unfamiliar to most people. The simple fix is to move it to an online service, when all those problems melt away. Simple. If on the other hand, anyone wants the considerable advantages of working offline without a server, well, then TiddlyWiki is the only thing on the planet that can help them, and it comes with a learning curve.

Elsewhere he also gave, I think, a useful, typology of users ...

* commercial services for general users

* easy Node.js app deployment for advanced DIY users

* continued support for the standalone configuration in the browser for most DIY users

 I'm very interested in "most DIY" users, being one, though not really competent yet, despite trying, so I fall between the classifications. I.e. probably "Wants to be DIY, but maybe should be using only online services" ... :-)

Naturally flows from this is my interest in what Jeremy is sensing about the state of play, since he likely understands it better than anyone.

That was the (my) point in exploring "Voicing Futures".

The issue IMO is not so much about the extant reality as a "conceptual orientation" to the future in some way.

Its better articulating that that interested me a lot.

TW seems difficult to form a full overview of. That is a lot to do with what it can DO. The many ways it can work. I do think its a bit of a barrier to entry. THAT is partly why Jeremy's comment   "The simple fix is to move it to an online service, when all those problems melt away" is so interesting.

BUT what is meant here by "online service" is what I am trying to grasp better.

I personally would NOT say that either "online" or "commercial" services (are there any commercial ones yet?) are yet quite transparent enough or obvious for "general users". Perhaps I am wrong?

 Best wishes
Josiah