Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

It's not really a locking system like you describe. Instead, it basically 
works by comparing the contents of the data that was saved last time to 
what it reads off of the disk. If it doesn't match what it expects, an 
error is reported. It uses hashing to make this take less memory, but that 
doesn't make that much of a difference besides reducing memory consumption.

My suggested route for recovery if an error is reported there is to attempt 
to save again. It will fall back to the download saver and you will have to 
merge the two versions manually using tiddler import/export.

I've uploaded a YouTube video demonstrating how the check works. Note that 
since the plugin only cares about contents, the wiki needs to be 
non-identical (usually happens immediately due to modification timestamps).

https://youtu.be/F6HZo1e-5k8

It would definitely be possible to store a session fingerprint in local 
storage or IndexedDB to check for issues locally. However, that doesn't 
prevent issues with concurrent modifications from different browsers or on 
different computers via network drives.
On Tuesday, February 22, 2022 at 7:47:20 PM UTC-8 TW Tones wrote:

> Dylon,
>
> *One of the reasons for introducing the save button at startup is so the 
> plugin can quickly read the original file and compute its file hash as soon 
> as possible.*
>
> In some of my own experiments, in a startup action if the wiki is 
> available for editing I immediately save and reload it to indicate this 
> session "owns it". Similarly when finished the final save needs to release 
> it.
>
>- With a splash screen advising its loading this may be ok because in 
>need only be done once per session (that has the wiki for edit/save) even 
>on larger wikis.
>
>
> I have come across two issues;
>
>- The browser session needs a finger print to be saved in local 
>storage, so this can be compared with the loaded copy of the wiki to check 
>ownership
>   - I have found an almost unique fingerprint
>- If the wiki is on file:// I have not found how to get a seperate 
>finger print for each tab, so it could be opened in more than one tab and 
>save will only save the current tabs changes.
>
> Have you found a way to open a file:// wiki in two tabs and not confuse 
> the session?
>
> On Wednesday, 23 February 2022 at 13:09:32 UTC+11 dyllon...@gmail.com 
> wrote:
>
>> For contention, the current version actually does provide some integrity 
>> measures. One of the reasons for introducing the save button at startup is 
>> so the plugin can quickly read the original file and compute its file hash 
>> as soon as possible.
>>
>> One the first save (i.e. when you click the button on the launch modal), 
>> the hash of the serialized wiki is recorded. On subsequent saves, the 
>> plugin compares the hash of the new version to the hash of the old version 
>> to see if the file has changed unexpectedly (i.e. changes were made in a 
>> different browser pane or it is on a network drive and someone else changed 
>> it).
>>
>> I'm hesitant to rely too much on Tiddlywiki internals to try and maintain 
>> forward compatibility, but it would be nice if this check were possible 
>> without triggering an actual save. The other reason is to avoid unexpected 
>> prompts when autosaving things obviously.
>>
>> I will also admit that as a software developer, I'm not the best person 
>> at making people understand the saving mechanism without overwhelming them 
>> with technical details.
>>
>> As for using a more intuitive save button, I'm welcome to suggestions 
>> and/or pull requests so long as things scale for different browser/wiki 
>> layouts and it doesn't pull in any large images (an SVG or something would 
>> probably be ok). I agree the button used right now is kind of ugly. Another 
>> thing to keep in mind with suggestions is that people might be using 
>> different color schemes which I'd like the plugin to try and respect.
>>
>> Thanks for your feedback!
>>
>> On Friday, February 18, 2022 at 5:13:26 PM UTC-8 TW Tones wrote:
>>
>>> Folks,
>>>
>>> I believe this is already available on tiddlywiki.com at 
>>> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API
>>>
>>> It is not yet comprehensively documented and it is hard for me to 
>>> determine what level of functionality and customisation is available to us. 
>>> As a solution only on Chromium browsers it is not yet global in 
>>> application, so understanding its value is even harder to determine.
>>>
>>> I also ask myself "We require a click event to start the save dialogue" 
>>> if this could not be placed in a save button "lookalike" or another way to 
>>> make it user friendly. Ie just in time, not startup, Although in this 
>>> thread others suggest they do not need it.
>>>
>>> Can someone write a user designer perspective and/or comparison with 
>>> existing methods?
>>>
>>> My concerns;
>>>
>>>- How to design online tiddlywikis 

[tw5] Enhancements Step 1: tiddlers to run BASIC in TiddlyWiki

[Charlie Veniot]

Follow-up to Minimal Tiddlers (2) to run BASIC in TiddlyWiki 


To explain the architecture of BASIC Anywhere Machine, I'm going to 
demonstrate the organic evolutionary steps from the minimal (2) tiddlers to 
run wwwBASIC programs in TiddlyWiki to the architecture of today/tomorrow.

The next step, as draft-described in the slideshow presentation I'm working 
on 
,
 
is about separating the tiddler for a wwwBASIC web page into:

   - a tiddler with the scheme for the web page
   - a tiddler with the wwwBASIC program

To render the wwwBASIC web page, the "renderer" now needs the smarts to 
merge the two tiddlers above, feeding the result of the merge to an iframe.

Once you've had a chance to try the previous 2-tiddler setup, download the 
attached and import into some TiddlyWiki (TiddlyWiki.com !) to dissect this 
3-tiddler evolution.

Cheers !


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/43a6f40f-7325-4cf4-90af-fe83ac82f174n%40googlegroups.com.


Enhancements_Step1_TiddlersForBasicPrograms.json
Description: application/json

Re: [tw5] Major updates to Chromium native file system saver plugin

[TW Tones]

Dylon,

*One of the reasons for introducing the save button at startup is so the 
plugin can quickly read the original file and compute its file hash as soon 
as possible.*

In some of my own experiments, in a startup action if the wiki is available 
for editing I immediately save and reload it to indicate this session "owns 
it". Similarly when finished the final save needs to release it.

   - With a splash screen advising its loading this may be ok because in 
   need only be done once per session (that has the wiki for edit/save) even 
   on larger wikis.


I have come across two issues;

   - The browser session needs a finger print to be saved in local storage, 
   so this can be compared with the loaded copy of the wiki to check ownership
  - I have found an almost unique fingerprint
   - If the wiki is on file:// I have not found how to get a seperate 
   finger print for each tab, so it could be opened in more than one tab and 
   save will only save the current tabs changes.

Have you found a way to open a file:// wiki in two tabs and not confuse the 
session?

On Wednesday, 23 February 2022 at 13:09:32 UTC+11 dyllon...@gmail.com wrote:

> For contention, the current version actually does provide some integrity 
> measures. One of the reasons for introducing the save button at startup is 
> so the plugin can quickly read the original file and compute its file hash 
> as soon as possible.
>
> One the first save (i.e. when you click the button on the launch modal), 
> the hash of the serialized wiki is recorded. On subsequent saves, the 
> plugin compares the hash of the new version to the hash of the old version 
> to see if the file has changed unexpectedly (i.e. changes were made in a 
> different browser pane or it is on a network drive and someone else changed 
> it).
>
> I'm hesitant to rely too much on Tiddlywiki internals to try and maintain 
> forward compatibility, but it would be nice if this check were possible 
> without triggering an actual save. The other reason is to avoid unexpected 
> prompts when autosaving things obviously.
>
> I will also admit that as a software developer, I'm not the best person at 
> making people understand the saving mechanism without overwhelming them 
> with technical details.
>
> As for using a more intuitive save button, I'm welcome to suggestions 
> and/or pull requests so long as things scale for different browser/wiki 
> layouts and it doesn't pull in any large images (an SVG or something would 
> probably be ok). I agree the button used right now is kind of ugly. Another 
> thing to keep in mind with suggestions is that people might be using 
> different color schemes which I'd like the plugin to try and respect.
>
> Thanks for your feedback!
>
> On Friday, February 18, 2022 at 5:13:26 PM UTC-8 TW Tones wrote:
>
>> Folks,
>>
>> I believe this is already available on tiddlywiki.com at 
>> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API
>>
>> It is not yet comprehensively documented and it is hard for me to 
>> determine what level of functionality and customisation is available to us. 
>> As a solution only on Chromium browsers it is not yet global in 
>> application, so understanding its value is even harder to determine.
>>
>> I also ask myself "We require a click event to start the save dialogue" 
>> if this could not be placed in a save button "lookalike" or another way to 
>> make it user friendly. Ie just in time, not startup, Although in this 
>> thread others suggest they do not need it.
>>
>> Can someone write a user designer perspective and/or comparison with 
>> existing methods?
>>
>> My concerns;
>>
>>- How to design online tiddlywikis with a non-intrusive saving 
>>mechanism users can understand.
>>- Dealing with the contention possible with two parties editing the 
>>same site.
>>
>> I would appreciate it is someone can spell this out a little more for us 
>> who need it, and can't easily understand this from the jargon and reading 
>> between the lines in this discussion.
>>
>> Thanks
>> Tones
>> On Wednesday, 9 February 2022 at 11:10:40 UTC+11 PMario wrote:
>>
>>> Hi,
>>> I do like that option. 
>>> -mario
>>>
>>> On Wednesday, February 9, 2022 at 12:11:06 AM UTC+1 dyllon...@gmail.com 
>>> wrote:
>>>
 It does work, though I think it is disruptive asking as soon as 
 something is done which triggers autosave. However, I have put in an 
 option 
 with version 0.7.1 to disable the modal for those who don't like it.

 On Sunday, February 6, 2022 at 1:46:16 AM UTC-8 PMario wrote:

> On Sunday, February 6, 2022 at 12:54:25 AM UTC+1 brian@gmail.com 
> wrote:
> ...
>
>> Now with the indexdb entry re-populated, the sequence looks like this:
>>
>>1. Reload the TW page
>>2. Click the + button to create a new tiddler
>>3. Click the checkmark to save the tiddler
>>4. A dialog box asks me if I want to 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

Jeremy, is there an easy way to serialize the wiki to a string without 
triggering a save? That would allow me to give a better integrity check if 
people don't save immediately. I can't just "await 
fetch("./example-wiki.html")" because of dumb browser restrictions with 
file://. That was what I initially tried to do.

Thanks,
Dyllon

On Sunday, February 20, 2022 at 3:32:50 AM UTC-8 jeremy...@gmail.com wrote:

> Hi Brian,
>
> I seem to recall https://tiddlywiki.fission.app/ implements such a 
> launcher,
>
>
> That’s right. TiddlyDesktop also has a similar architecture. The challenge 
> with Fission is that images stored in ones Fission drive are not accessible 
> via a URL; there’s just a JS API to retrieve specific files. I have 
> experimented with using a service worker to map local URLs to the JS API, 
> which I think might be a promising generic technique for working with 
> non-URL-based storage.
>
> but currently that page has an endlessly spinning "Authorizing with 
> fission" message and the console has an "Uncaught (in promise) Error: 
> Improperly formatted header value: skeleton" in webnative.js, so I couldn't 
> confirm my memory.
>
>
> I hope to be able to work on TiddlyWiki on Fission soon, and will make an 
> update to the latest version of the SDK.
>
> Best wishes
>
> Jeremy
>
> I think the workflow implemented by the above two apps is "safer" than 
> what I saw in the TW chromium native file saver. With the TW native saver 
> the workflow looks like this:
>
>1. Load my native saver enabled TW using some url (possibly a file:// 
>url)
>2. Click the Save button in HTML Native File System Saver modal
>3. From the file dialog select the same file I'm already editing
>4. Dialog box "a file with this name already exists, do you want to 
>replace it?"
>5. Start sweating a little bit...if I've chosen the wrong file here, I 
>might be overwriting something important
>6. Sweat a little bit more especially if I've loaded it from a web url 
>where it isn't as easy to tell that I've selected the matching file or not
>7. Cross my fingers, click the "replace" button and hope for the best
>
> The bangle and diagrams.net applications don't have the same room for 
> user error since you are prompted for what file to read and then it 
> automatically saves back to that same file. I find that workflow to be less 
> nerve-wracking.
>
> Maybe with tiddlywiki's unique structure there is an even better workflow 
> to be had, I don't know. And maybe the TW nativesaver can already be used 
> with a better workflow and I just missed it.
>  
>
>> On Fri, 18 Feb 2022 at 20:13, TW Tones  wrote:
>>
>>> Folks,
>>>
>>> I believe this is already available on tiddlywiki.com at 
>>> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API
>>>
>>> It is not yet comprehensively documented and it is hard for me to 
>>> determine what level of functionality and customisation is available to us. 
>>> As a solution only on Chromium browsers it is not yet global in 
>>> application, so understanding its value is even harder to determine.
>>>
>>> I also ask myself "We require a click event to start the save dialogue" 
>>> if this could not be placed in a save button "lookalike" or another way to 
>>> make it user friendly. Ie just in time, not startup, Although in this 
>>> thread others suggest they do not need it.
>>>
>>> Can someone write a user designer perspective and/or comparison with 
>>> existing methods?
>>>
>>> My concerns;
>>>
>>>- How to design online tiddlywikis with a non-intrusive saving 
>>>mechanism users can understand.
>>>- Dealing with the contention possible with two parties editing the 
>>>same site.
>>>
>>> I would appreciate it is someone can spell this out a little more for us 
>>> who need it, and can't easily understand this from the jargon and reading 
>>> between the lines in this discussion.
>>>
>>> Thanks
>>> Tones
>>> On Wednesday, 9 February 2022 at 11:10:40 UTC+11 PMario wrote:
>>>
 Hi,
 I do like that option. 
 -mario

 On Wednesday, February 9, 2022 at 12:11:06 AM UTC+1 dyllon...@gmail.com 
 wrote:

> It does work, though I think it is disruptive asking as soon as 
> something is done which triggers autosave. However, I have put in an 
> option 
> with version 0.7.1 to disable the modal for those who don't like it.
>
> On Sunday, February 6, 2022 at 1:46:16 AM UTC-8 PMario wrote:
>
>> On Sunday, February 6, 2022 at 12:54:25 AM UTC+1 brian@gmail.com 
>> wrote:
>> ...
>>
>>> Now with the indexdb entry re-populated, the sequence looks like 
>>> this:
>>>
>>>1. Reload the TW page
>>>2. Click the + button to create a new tiddler
>>>3. Click the checkmark to save the tiddler
>>>4. A dialog box asks me if I want to let the site edit the file. 
>>>I click the "edit file" button
>>>

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

I actually implemented something similar in an experimental branch to the 
launcher idea a while back but abandoned it because it felt very clunky to 
me  slaymaker1907/TW5-browser-nativesaver at sync-adaptor (github.com) 

.

The biggest problem was that sync adaptors don't work as nicely as regular 
savers with falling back to another saver in case of errors. If people were 
interested in that approach, it would probably be better done as a separate 
plugin and just duplicate code since savers work very differently compared 
to sync modules. It's also a lot more work since there is much less 
documentation on sync adaptors compared to vanilla saver modules.

One thing I still like about the sync adaptor/folder wiki idea is that 
versioning can be done much more cheaply (at the cost of recovery 
complexity if you want to go back to an old version). Instead of just 
saving the whole wiki each time, the plugin could just save the old version 
of the changed tiddlers.

If the API supported it, I'd love to just save the old versions in a 
compressed file so it takes up less space. However, that isn't really 
practical since JSZip is a huge dependency for one plugin and because the 
file system API can't do changes in place. You have to completely write the 
whole file each time.

Thinking about that issue though, I could possibly implement gzip 
compression for the individual versioned files. Plain gzip at level 5 gives 
a compression ratio of ~17% for the example wiki (so compressed it is 17% 
the size of the original) which is quite a bit. I don't want to do some 
sort of diff or patch algorithm since I don't know if I trust myself enough 
to implement such a thing correctly plus you can't just use 7zip in that 
case to recover the data. isomorphic-git · A pure JavaScript implementation 
of git for node and browsers!  might also 
work so it's just a git repo in that case.

In terms of stressing if you picked the right file, assuming you used the 
modal button, you don't need to stress out too much since the consistency 
check should catch that.
On Saturday, February 19, 2022 at 5:45:06 AM UTC-8 brian@gmail.com 
wrote:

> On Fri, Feb 18, 2022 at 8:16 PM Frédéric Demers  
> wrote:
>
>> As inspiration, this seems to be a decent implementation of native file 
>> storage API: https://bangle.io
>>
>
> This does look pretty good. Another example is https://app.diagrams.net/.
>
> These two apps have a webpage at a well-known url which holds the 
> javascript functionality. The data files are loaded in separately. Compare 
> this to tiddlywiki in which the functionality and the data is combined 
> together into a single file.
>
> I think to implement the same workflow in tiddlywiki, you'd have to have a 
> "launcher" instance of tiddlywiki which would read a tiddlywiki instance 
> from disk as the "data file".
>
> I seem to recall https://tiddlywiki.fission.app/ implements such a 
> launcher, but currently that page has an endlessly spinning "Authorizing 
> with fission" message and the console has an "Uncaught (in promise) Error: 
> Improperly formatted header value: skeleton" in webnative.js, so I couldn't 
> confirm my memory.
>
> I think the workflow implemented by the above two apps is "safer" than 
> what I saw in the TW chromium native file saver. With the TW native saver 
> the workflow looks like this:
>
>1. Load my native saver enabled TW using some url (possibly a file:// 
>url)
>2. Click the Save button in HTML Native File System Saver modal
>3. From the file dialog select the same file I'm already editing
>4. Dialog box "a file with this name already exists, do you want to 
>replace it?"
>5. Start sweating a little bit...if I've chosen the wrong file here, I 
>might be overwriting something important
>6. Sweat a little bit more especially if I've loaded it from a web url 
>where it isn't as easy to tell that I've selected the matching file or not
>7. Cross my fingers, click the "replace" button and hope for the best
>
> The bangle and diagrams.net applications don't have the same room for 
> user error since you are prompted for what file to read and then it 
> automatically saves back to that same file. I find that workflow to be less 
> nerve-wracking.
>
> Maybe with tiddlywiki's unique structure there is an even better workflow 
> to be had, I don't know. And maybe the TW nativesaver can already be used 
> with a better workflow and I just missed it.
>  
>
>> On Fri, 18 Feb 2022 at 20:13, TW Tones  wrote:
>>
>>> Folks,
>>>
>>> I believe this is already available on tiddlywiki.com at 
>>> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API
>>>
>>> It is not yet comprehensively documented and it is hard for me to 
>>> determine what level of functionality and customisation is available to us. 
>>> As a solution only 

Re: [tw5] Major updates to Chromium native file system saver plugin

[Dyllon Gagnier]

For contention, the current version actually does provide some integrity 
measures. One of the reasons for introducing the save button at startup is 
so the plugin can quickly read the original file and compute its file hash 
as soon as possible.

One the first save (i.e. when you click the button on the launch modal), 
the hash of the serialized wiki is recorded. On subsequent saves, the 
plugin compares the hash of the new version to the hash of the old version 
to see if the file has changed unexpectedly (i.e. changes were made in a 
different browser pane or it is on a network drive and someone else changed 
it).

I'm hesitant to rely too much on Tiddlywiki internals to try and maintain 
forward compatibility, but it would be nice if this check were possible 
without triggering an actual save. The other reason is to avoid unexpected 
prompts when autosaving things obviously.

I will also admit that as a software developer, I'm not the best person at 
making people understand the saving mechanism without overwhelming them 
with technical details.

As for using a more intuitive save button, I'm welcome to suggestions 
and/or pull requests so long as things scale for different browser/wiki 
layouts and it doesn't pull in any large images (an SVG or something would 
probably be ok). I agree the button used right now is kind of ugly. Another 
thing to keep in mind with suggestions is that people might be using 
different color schemes which I'd like the plugin to try and respect.

Thanks for your feedback!

On Friday, February 18, 2022 at 5:13:26 PM UTC-8 TW Tones wrote:

> Folks,
>
> I believe this is already available on tiddlywiki.com at 
> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API
>
> It is not yet comprehensively documented and it is hard for me to 
> determine what level of functionality and customisation is available to us. 
> As a solution only on Chromium browsers it is not yet global in 
> application, so understanding its value is even harder to determine.
>
> I also ask myself "We require a click event to start the save dialogue" if 
> this could not be placed in a save button "lookalike" or another way to 
> make it user friendly. Ie just in time, not startup, Although in this 
> thread others suggest they do not need it.
>
> Can someone write a user designer perspective and/or comparison with 
> existing methods?
>
> My concerns;
>
>- How to design online tiddlywikis with a non-intrusive saving 
>mechanism users can understand.
>- Dealing with the contention possible with two parties editing the 
>same site.
>
> I would appreciate it is someone can spell this out a little more for us 
> who need it, and can't easily understand this from the jargon and reading 
> between the lines in this discussion.
>
> Thanks
> Tones
> On Wednesday, 9 February 2022 at 11:10:40 UTC+11 PMario wrote:
>
>> Hi,
>> I do like that option. 
>> -mario
>>
>> On Wednesday, February 9, 2022 at 12:11:06 AM UTC+1 dyllon...@gmail.com 
>> wrote:
>>
>>> It does work, though I think it is disruptive asking as soon as 
>>> something is done which triggers autosave. However, I have put in an option 
>>> with version 0.7.1 to disable the modal for those who don't like it.
>>>
>>> On Sunday, February 6, 2022 at 1:46:16 AM UTC-8 PMario wrote:
>>>
 On Sunday, February 6, 2022 at 12:54:25 AM UTC+1 brian@gmail.com 
 wrote:
 ...

> Now with the indexdb entry re-populated, the sequence looks like this:
>
>1. Reload the TW page
>2. Click the + button to create a new tiddler
>3. Click the checkmark to save the tiddler
>4. A dialog box asks me if I want to let the site edit the file. I 
>click the "edit file" button
>5. The file saves
>
> So it is working for me even without the settings modal. Do you see 
> this same behavior?
>

 I also think the modal isn't needed. The API requires user interaction. 
 ... But I think the described behaviour is good. The permission is 
 requested, when the first save happens. Since this save is a user 
 interaction it should be good enough.

 -mario

>>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/934341cb-bca7-444c-991d-a02fed018d9en%40googlegroups.com.

[tw5] Re: Prepping a BASIC Anywhere Machine "architecture" presentation, suggestions?

[Hans Wobbe]

cj.:

I'm not sure I can qualify as a "soul", but I think I can at least offer to 
make comments about how I thinbk I might wabt to use these capabilities.

Cheers,
Hans

On Monday, February 21, 2022 at 8:42:21 PM UTC-5 cj.v...@gmail.com wrote:

> I'd like to put together a comprehensive slideshow for a presentation on 
> YouTube.
>
> Although pretty much just a blank page at the moment, I figured might as 
> well publish the slideshow document 
> 
>  
> now, in case there is a soul out there that is interested in this kind of 
> thing, and might want to suggest things that would answer questions, or 
> what-have-you.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/ddda8404-bf60-4aa6-aab6-3f0b7699559bn%40googlegroups.com.

[tw5] Re: Tiddlywiki + Google Spreasheets. I want to show you my newer finished work

[Siniy-Kit]

Yes, I use  js function  to read external JSONP " in your tidder under 
"Начало 
нового кода"   just open it 
   in is very simple. 
It works faster then FETCH
To test it work open https://heeg.ru/shop2_3.html#%24%3A%2FControlPanel  
and press "*залить данные из гугл таблицы СЕЙЧАС*"  spreadsheet must have 
lists "goods, parts, images, system"   So you have to rewrite my code not 
to use this lists names. Here are examples, how we can use google 
spreadsheet id in URL  
 https://groups.google.com/g/heeg/c/G0eSqbJBvZg/m/9Jr0dtu6CAAJ
2. I dont use  doGET() and  doPOST() in my projects now,  but I plan to use 
it, because it is new and more interesting instrument of googlespreadsheet 

понедельник, 21 февраля 2022 г. в 22:57:14 UTC+3, Mat: 

> Siniy-Kit wrote:
>
>> 1) very very very old JSONP (*I use it now*)
>>
>> https://spreadsheets.google.com/tq?key=16jpYS8egNJuLA8HyS-Um6wuwC9A5eFl-IKykIzZB92Y=goods
>> here we have js function  with JSON 
>> argument. google.visualization.Query.setResponse({..})
>>
>
> So... the output in that link is a js function and some more stuff that 
> wraps the JSON. So, do you *scrub off* the wrapping stuff to accss the 
> clean JSON content or do you *use* the js function in your own code? 
> ...and is the scrubbing or use of the js function what you have in your 
> tidder under "Начало нового кода" ?
>  
>
>> 2) new variant with doGET() in google script
>>
>
> This looks very interesting. If I interpret these docs 
> , 
> it seems very direct to both get and post content from and to a sheet 
> (which is one big limitation in the current TiddlyGoo solutions; there is 
> no solution to push data to a sheet from TW). 
> But, @Siniy-kit, you currently don't use doGet or doPost at all, right? 
> You solve *both* push and pull with JSONP, right?
>
> Thank you for your replies.
>
> <:-)
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/87af9a75-83fe-4e98-a0c4-dffa19945752n%40googlegroups.com.