adding a remote tiddler from github

[joearms]

I'd like some feedback on some tiddlers I've been writing.

If I publish the tidders on github (ie the individual tiddlers and NOT an entire TW)

is there a syntax that can be used that can yank in and view the tiddler from any other

TW?)

I realise this breaks security - but would be very convenient - can the remote tiddler be run in a 

iframe? or some other trusted mode?

Cheers

/Joe

[@TiddlyTweeter]

Do you have an address?

[joearms]

As followup - suppose I had a long list of tiddlers given by URLs

say

          [http://some.web.site/path/to/MyTiddler.tid,

           ...]

This could be quite long. It's rather easy to programmatically gather these and store them locally (and check for updates)

If I gather all of these - dump them in a sub directory of 'tidders' and restart the node server then I could build

specialist TW's from lists of tiddlers.

Is this a good way to collaborate? It means the granularity of collaboration becomes a single tiddler and not

and entire TW.

Just a thought

Cheers

/Joe

On Sunday, 16 December 2018 11:43:26 UTC+1, joearms wrote:

[joearms]

[joearms]

Not yet - I'll make a GitHub project and add a few tiddlers later today.

I've started writing up a guide to the TW which I'd appreciate some feedback on. See if I've

correctly described how things work.

/Joe

On Sunday, 16 December 2018 15:30:02 UTC+1, @TiddlyTweeter wrote:

[Jeremy Ruston]

Hi Joe

We can do that from Node.js (running in the browser we can only retrieve from HTTP endpoints that are CORS enabled).

There’s a “fetch” command that retrieves tiddlers over HTTP that ought to be able to do the job:

tiddlywiki editions/empty/ --verbose --fetch file https://raw.githubusercontent.com/Jermolene/TiddlyWiki5/master/editions/dev/tiddlers/HelloThere.tid '[!is[system]]' '' --build index

It’s intended for exactly this kind of use case.

https://tiddlywiki.com/#FetchCommand

In particular, a useful arrangement is to save the URLs of the files you’re importing in the URL field of tiddlers tagged, say, “remote-server”, and then you can use a filter to specify a bunch of URLs to read:

tiddlywiki editions/empty/ --verbose --fetch files '[tag[remote_server]get[url]]' '[!is[system]]' '' --build index

However, it doesn’t work with GitHub at the moment because it returns all files with the content type “text/plain” which confuses the import mechanism. We could fix this easily enough by allowing an override content type to be specified as an additional command parameter.

Best wishes

Jeremy.

Cheers

/Joe

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/13edcef6-3cff-495b-a18f-4858855821ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[joearms]

I made a couple of tiddlers here:

• https://joearms.github.io/tiddlers/SharedTiddlers.tid
• https://joearms.github.io/tiddlers/A programmers introduction to the TiddlyWiki.tid

These pages are made automatically when I push to

https://github.com/joearms/joearms.github.io/tree/master/tiddlers

These are pretty unchecked - I just want to check you can access them. Typos/corrections/etc

can be made by pushing changes in the master/tiddlers directory above

Can you auto import these???

Cheers

/Joe

On Sunday, 16 December 2018 15:30:02 UTC+1, @TiddlyTweeter wrote:

[joearms]

On Sunday, 16 December 2018 18:18:50 UTC+1, Jeremy Ruston wrote:

Hi Joe

I'd like some feedback on some tiddlers I've been writing.

If I publish the tidders on github (ie the individual tiddlers and NOT an entire TW)

is there a syntax that can be used that can yank in and view the tiddler from any other

TW?)

I realise this breaks security - but would be very convenient - can the remote tiddler be run in a 

iframe? or some other trusted mode?

We can do that from Node.js (running in the browser we can only retrieve from HTTP endpoints that are CORS enabled).

There’s a “fetch” command that retrieves tiddlers over HTTP that ought to be able to do the job:

tiddlywiki editions/empty/ --verbose --fetch file https://raw.githubusercontent.com/Jermolene/TiddlyWiki5/master/editions/dev/tiddlers/HelloThere.tid '[!is[system]]' '' --build index

It’s intended for exactly this kind of use case.

https://tiddlywiki.com/#FetchCommand

In particular, a useful arrangement is to save the URLs of the files you’re importing in the URL field of tiddlers tagged, say, “remote-server”, and then you can use a filter to specify a bunch of URLs to read:

tiddlywiki editions/empty/ --verbose --fetch files '[tag[remote_server]get[url]]' '[!is[system]]' '' --build index

However, it doesn’t work with GitHub at the moment because it returns all files with the content type “text/plain” which confuses the import mechanism. We could fix this easily enough by allowing an override content type to be specified as an additional command parameter.

Interesting the github pages serves the tiddlers up with

Content-Type: application/octet-stream

:-)

/Joe

[Jeremy Ruston]

Hi Joe

I can see the files but but they don’t import at the moment because of the content-type problem mentioned above.

I’ve attached a quick and dirty patch that gets things working.

tiddlywiki editions/empty/ --verbose --fetch file https://joearms.github.io/tiddlers/SharedTiddlers.tid '[!is[system]]' '' --build index

Best wishes

Jeremy.

[joearms]

A couple of comments

1) I like the idea of collaborating at the level of "single tiddlers"

    All I have to do is put a single tiddler on github and publish the address and off we go.

2) Bundles of related tiddlers could be published with names like Tiddler.tid.zip (or something)

3) I suspect github or Google pages or (whatever) will muck with the content-types and so on

but it would be easy to just define "tiddlers over HTTP" - just send them as regular HTTP pages

where the Body is tiddler (headers and all) - ie the .tid file verbatim.

4) It seems to me the creating an entire TW (as a single all-in-one file) is a job of collating and selecting

which tiddlers you want to appear in the final TW.

Of course, many users will not want this fine level of granularity - but I rather like the idea of 'remoting' 

individual tiddlers.

Really this is a discussion about what I might call "the granularity of collaboration" - which I think is an individual tiddler.

When I've written books most of the discussion with my editor has been over individual paragraphs and not the 

whole - put the parts together into the whole is a different exercise.

It could be quite fun. See my

• https://joearms.github.io/tiddlers/A programmers introduction to the TiddlyWiki.tid

I can image people pushing minor changes to this, or proposing alternatives - getting the individual tiddlers right

seems a nice step *before* assembling the parts into the whole. Of course, this is an approximation and the two phases

writing tiddlers and assembling them into larger parts cannot be separated - but the TW allow seamless flipping between these two modes.

Fun stuff

Cheers

/Joe

On Sunday, 16 December 2018 18:18:50 UTC+1, Jeremy Ruston wrote:

[Jeremy Ruston]

Hi Joe

A couple of comments

1) I like the idea of collaborating at the level of "single tiddlers"

    All I have to do is put a single tiddler on github and publish the address and off we go.

2) Bundles of related tiddlers could be published with names like Tiddler.tid.zip (or something)

You can use a JSON file as a container for multiple tiddlers. The format is:

[

    {

        "title": "HelloThere",

        "text": "Foo",

        "type": "text/vnd.tiddlywiki",

        "tags": "TableOfContents",

        "modified": "20181206090053690",

        "created": "20130822170200000"

    },

    {

        "title": "GettingStarted",

        "text": "Bar",

        "type": "text/vnd.tiddlywiki",

        "tags": "TableOfContents",

        "modified": "20181206090053690",

        "created": "20130822170200000"

    }

]

3) I suspect github or Google pages or (whatever) will muck with the content-types and so on

but it would be easy to just define "tiddlers over HTTP" - just send them as regular HTTP pages

where the Body is tiddler (headers and all) - ie the .tid file verbatim.

I’d like to be able to support the current range of tiddler file types, either by specifying an override content type, or perhaps by sniffing the file extension.

4) It seems to me the creating an entire TW (as a single all-in-one file) is a job of collating and selecting

which tiddlers you want to appear in the final TW.

Of course, many users will not want this fine level of granularity - but I rather like the idea of 'remoting' 

individual tiddlers.

Really this is a discussion about what I might call "the granularity of collaboration" - which I think is an individual tiddler.

When I've written books most of the discussion with my editor has been over individual paragraphs and not the 

whole - put the parts together into the whole is a different exercise.

It could be quite fun. See my

• https://joearms.github.io/tiddlers/A programmers introduction to the TiddlyWiki.tid

Excellent stuff, that’s a good perspective to write from.

I can image people pushing minor changes to this, or proposing alternatives - getting the individual tiddlers right

seems a nice step *before* assembling the parts into the whole. Of course, this is an approximation and the two phases

writing tiddlers and assembling them into larger parts cannot be separated - but the TW allow seamless flipping between these two modes.

Indeed, the “twederation” dream is to be able to do all of this without GitHub, too.

Best wishes

Jeremy

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/0c3515a1-b957-4c66-b470-e9fd8c3ce85c%40googlegroups.com.

[Diego Mesa]

Hey all,

Is this not a good way to keep plugins and even the core auto-updated? 

[Jeremy Ruston]

Hi Diego

Is this not a good way to keep plugins and even the core auto-updated? 

The fetch command only works under Node.js and not within the browser.

As noted above, we can make HTTP requests in the browser but we're restricted to endpoints that are CORS enabled, which GitHub Pages is not. That's why the plugin library is based on loading the library in an iframe and communicating with it via window.postMessage.

Best wishes

Jeremy

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/2a5a20bf-37e2-46c9-9285-ee343336409b%40googlegroups.com.

[Diego Mesa]

Hey Jeremy,

I could imagine the node version (requiring "extra" steps anyway) supporting auto-updating of plugins/core, while the single-file version is more like a "frozen" wiki you have to manually upgrade. 

[Jeremy Ruston]

Hi Diego

I could imagine the node version (requiring "extra" steps anyway) supporting auto-updating of plugins/core, while the single-file version is more like a "frozen" wiki you have to manually upgrade. 

The procedure under Node.js for updating the core and plugins from the official library is to use the `npm update` command. As per the original discussion here, the fetch command could be used under Node.js to fetch the latest versions of plugins/tiddlers — it was added as the means to implement Twederation under Node.js.

Best wishes

Jeremy.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/1198347d-1491-41c9-a4e4-eb6127f23c12%40googlegroups.com.