[tw5] Re: Taking Node Server to the next level

[Mohamed Amin]

Hello All,

As I'm currently in the research phase in the same direction (which is very 
interested to me), please check my two cents https://gohugo.io/ and its Github 
Repo ,

Best Regards
Mohamed Amin

On Friday, November 29, 2019 at 1:59:43 AM UTC+2, Arlen Beiler wrote:
>
> I have a radical proposal which would take data folders to the next level. 
> What if instead of the file system adapter we would write a new adapter to 
> use a database. We could use PouchDB, but I would vote for something much 
> more widespread like SQLite. We could also write it in a generic way that 
> makes it easy to use with the regular SQL databases. It would be easy to 
> build but I would want to make it robust enough to use in a wide array of 
> platforms. 
>
> I have already worked with the tiddler loading code enough to be certain 
> it is self contained and can easily be made asynchronous to accommodate 
> this feature. Or the preload tiddlers feature can be used, but I think it’s 
> better to separate out the loaders as Jeremy has mentioned. 
>
> Any thoughts on this or things I should keep in mind as I brainstorm? 
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/15c5b77b-a122-475e-bdf1-3b1fe8293724%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[TonyM]

Bimlas

I would love to enable contributions to tiddler content via got hub a bit like 
when you edit tiddlywiki.com but have the changes appear online. We could open 
our published editions to issues and changes. But your idea sounds even better.

Regards
Tony

-- 
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/8360d34f-abb9-4ca8-9667-815aa3a83d03%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[bimlas]

There are two things that I think can be used for online storage:

On the one hand, the GitHub saver could be upgraded to save the tiddlers 
one at a time using the datafolder format instead of a large HTML (so you 
wouldn't have to wait minutes to save, just wait for one tiddler to save, 
like the Node server) work). This way, the wiki would be completely online, 
because when we save the changes, there would always be a commit that 
triggers the HTML wiki generation, so we could open it and modify it on 
GitHub without ever having to store it on our own machine.

My other idea is that Disqus, or a similar messaging system, can be used to 
store the tiddlers that we could access through the API.

For the time being, these are just ideas, but I will write them down to 
remember them and to give others ideas to complement.

-- 
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/5bb9370d-0f8c-4623-9033-94c8f7de42c5%40googlegroups.com.

Re: [tw5] Re: Taking Node Server to the next level

[bimlas]

Cozy link: https://docs.cozy.io/en/tutorials/konnector/scrape-data/
 

> Another option is Cozy, which, if I understand it, is a free online cloud. 
> This does not require the PouchDB saver, but a unique one, but may be used. 
> If I have more time, I'll dig into the saver world more.
>

-- 
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/93aa4048-f47d-4e62-b19e-cb446e068782%40googlegroups.com.

Re: [tw5] Re: Taking Node Server to the next level

[bimlas]

Arlen, Jed,

Thank you for supporting the community with your knowledge! Big respect!

Database backends look really useful. If I understand it, maybe even 
PouchDB can be solved online by Glitch: https://glitch.com/~pouchdb-server 
(click on show to fetch some data).

Another option is Cozy, which, if I understand it, is a free online cloud. 
This does not require the PouchDB saver, but a unique one, but may be used. 
If I have more time, I'll dig into the saver world more.

I don't know how Bob is solved, but here is a tutorial that can easily wrap 
both Tiddly and saver, so you can run it without installing Node.

-- 
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/197c1a68-0336-4750-aaa3-41372ab15342%40googlegroups.com.

Re: [tw5] Re: Taking Node Server to the next level

[Arlen Beiler]

And here's the link for it:

https://github.com/Arlen22/TW5-storage-plugin

On Mon, Dec 2, 2019 at 1:49 PM Arlen Beiler  wrote:

> Well, Jed's adapter and everyone's thoughts so far inspired me to do a
> little exploring and I managed to put this little proof of concept
> together. It turned out I did not need to touch the client at all and only
> modify four routes on the server. What's nice is that the index is still
> generated as usual so you can turn off the plugin and make changes to the
> initial HTML document if you want, then turn it back on and all your
> database tiddlers come back again. Almost like a template. The plugin is
> inside the data folder for now, but the npm install needs to be done in the
> tiddlywiki root folder (the folder containing tiddlywiki.js). The readme
> has rather simple instructions and the npm install command that needs to be
> run.
>
> On Mon, Dec 2, 2019 at 10:38 AM Arlen Beiler  wrote:
>
>> I think in this case I'm rather aiming to build something new on top of
>> TiddlyWiki5. I may revisit the rest of the TiddlyWeb protocol at a later
>> time and take some ideas from it. However, I think that to build something
>> new it would need to be built using TiddlyWiki5 from the ground up, whereas
>> tiddlyspot was built for TWC. That's just how I work best. For someone else
>> to take a different approach would not bother me at all.
>>
>> On Mon, Dec 2, 2019 at 5:30 AM mauloop  wrote:
>>
>>> Why not to reuse Tiddlyweb/Tiddlyspace work?
>>>
>>>- It has MySQL backend
>>>- It is multiuser and allows concurrent editing
>>>- It has public and private spaces
>>>- It uses the standard Node.js sync-adaptor
>>>- It works with TWC as well
>>>
>>> IMO it is a great piece of software. Not easy to set up. I did it on a
>>> local VM just to give it a try and Chris kindly helped me to solve some
>>> problems I fell into. I always feel bad when I see that good software falls
>>> into oblivion. Maybe it is not to be taken as is, but it could be a good
>>> starting point. Just to not reinvent the wheel.
>>>
>>> Another thought is... this is an old paradigm. PMario's suggestion (DAT
>>> protocol) goes one step beyond, moving towards the p2p paradigm. I use
>>> Syncthing to keep my devices synced. Both (DAT and Syncthing, which, I
>>> think, uses QUIC behind the scenes) provides versioning, encryption and,
>>> last but not least, ... privacy!
>>>
>>> TWedereation goes this direction too, isn't it?
>>>
>>> I have no much developing skills to contribute, but I would be happy to
>>> help testing if needed.
>>>
>>> )+(
>>>
>>> --
>>> 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/cb3cdfd0-e05a-417a-a329-1281e2064ecb%40googlegroups.com
>>> 
>>> .
>>>
>>

-- 
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/CAJ1vdSQyBDE-qMhT4UrUnFiwsKQxDTd-VpudxcOGnV6rCoz5HQ%40mail.gmail.com.

Re: [tw5] Re: Taking Node Server to the next level

[Arlen Beiler]

Well, Jed's adapter and everyone's thoughts so far inspired me to do a
little exploring and I managed to put this little proof of concept
together. It turned out I did not need to touch the client at all and only
modify four routes on the server. What's nice is that the index is still
generated as usual so you can turn off the plugin and make changes to the
initial HTML document if you want, then turn it back on and all your
database tiddlers come back again. Almost like a template. The plugin is
inside the data folder for now, but the npm install needs to be done in the
tiddlywiki root folder (the folder containing tiddlywiki.js). The readme
has rather simple instructions and the npm install command that needs to be
run.

On Mon, Dec 2, 2019 at 10:38 AM Arlen Beiler  wrote:

> I think in this case I'm rather aiming to build something new on top of
> TiddlyWiki5. I may revisit the rest of the TiddlyWeb protocol at a later
> time and take some ideas from it. However, I think that to build something
> new it would need to be built using TiddlyWiki5 from the ground up, whereas
> tiddlyspot was built for TWC. That's just how I work best. For someone else
> to take a different approach would not bother me at all.
>
> On Mon, Dec 2, 2019 at 5:30 AM mauloop  wrote:
>
>> Why not to reuse Tiddlyweb/Tiddlyspace work?
>>
>>- It has MySQL backend
>>- It is multiuser and allows concurrent editing
>>- It has public and private spaces
>>- It uses the standard Node.js sync-adaptor
>>- It works with TWC as well
>>
>> IMO it is a great piece of software. Not easy to set up. I did it on a
>> local VM just to give it a try and Chris kindly helped me to solve some
>> problems I fell into. I always feel bad when I see that good software falls
>> into oblivion. Maybe it is not to be taken as is, but it could be a good
>> starting point. Just to not reinvent the wheel.
>>
>> Another thought is... this is an old paradigm. PMario's suggestion (DAT
>> protocol) goes one step beyond, moving towards the p2p paradigm. I use
>> Syncthing to keep my devices synced. Both (DAT and Syncthing, which, I
>> think, uses QUIC behind the scenes) provides versioning, encryption and,
>> last but not least, ... privacy!
>>
>> TWedereation goes this direction too, isn't it?
>>
>> I have no much developing skills to contribute, but I would be happy to
>> help testing if needed.
>>
>> )+(
>>
>> --
>> 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/cb3cdfd0-e05a-417a-a329-1281e2064ecb%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAJ1vdSSe4-y4wR%3D6o_ihBmYe8E_bUqAgqT0tpb7LwaSpv7K9Uw%40mail.gmail.com.

Re: [tw5] Re: Taking Node Server to the next level

[Arlen Beiler]

I think in this case I'm rather aiming to build something new on top of
TiddlyWiki5. I may revisit the rest of the TiddlyWeb protocol at a later
time and take some ideas from it. However, I think that to build something
new it would need to be built using TiddlyWiki5 from the ground up, whereas
tiddlyspot was built for TWC. That's just how I work best. For someone else
to take a different approach would not bother me at all.

On Mon, Dec 2, 2019 at 5:30 AM mauloop  wrote:

> Why not to reuse Tiddlyweb/Tiddlyspace work?
>
>- It has MySQL backend
>- It is multiuser and allows concurrent editing
>- It has public and private spaces
>- It uses the standard Node.js sync-adaptor
>- It works with TWC as well
>
> IMO it is a great piece of software. Not easy to set up. I did it on a
> local VM just to give it a try and Chris kindly helped me to solve some
> problems I fell into. I always feel bad when I see that good software falls
> into oblivion. Maybe it is not to be taken as is, but it could be a good
> starting point. Just to not reinvent the wheel.
>
> Another thought is... this is an old paradigm. PMario's suggestion (DAT
> protocol) goes one step beyond, moving towards the p2p paradigm. I use
> Syncthing to keep my devices synced. Both (DAT and Syncthing, which, I
> think, uses QUIC behind the scenes) provides versioning, encryption and,
> last but not least, ... privacy!
>
> TWedereation goes this direction too, isn't it?
>
> I have no much developing skills to contribute, but I would be happy to
> help testing if needed.
>
> )+(
>
> --
> 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/cb3cdfd0-e05a-417a-a329-1281e2064ecb%40googlegroups.com
> 
> .
>

-- 
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/CAJ1vdSQNcg7eEZjiFuc%2BdoxbBOrC2Xu%3DbQGkAdJMZekgZhOtTA%40mail.gmail.com.

Re: [tw5] Re: Taking Node Server to the next level

[Arlen Beiler]

PouchDB is a very good first step because of the way it is setup. SQLite
would also be a great first step for targeting SQL databases.

On Sun, Dec 1, 2019 at 9:30 PM TonyM  wrote:

> Jed,
>
> Great work, what a Wiz. I will have a closer look. With the pouchDB have
> any more persistence that local storage I wonder?
>
> Such node solutions are great but we must find an easy way to host such
> things online when needed.
>
> Regards
> Tony
>
> On Monday, December 2, 2019 at 10:06:26 AM UTC+11, Jed Carty wrote:
>>
>> After finding out that I have very little idea how syncadaptors work I
>> started playing with making a new one and ended up with a working pouchdb
>> syncadaptor.
>>
>> It is very rough but it works, it will create a database and save
>> tiddlers to it, delete them when appropriate and then load the tiddlers
>> when you open it up again.
>>
>> At the moment the implementation is just for one wiki, but extending it
>> to have multiple wikis on the same node process would be very straight
>> forward.
>> It has potential for some things people have asked for like being able to
>> search all tiddlers in all available wikis.
>>
>> As a note, this is not noteself, while it could be configured to connect
>> to a remote database, either pouchdb or CouchDB, it doesn't have any of the
>> nice features of noteself other than saving to a database.
>>
>> Considering how straight froward this was making similar adaptors that
>> work with the various flavours of sql databases wouldn't be too hard aside
>> from figuring out the appropriate database schema. That is something I have
>> absolutely no interest in doing but this may work as a reasonable reference
>> design for anyone who wants to make a sql database adaptor.
>>
>> There are instructions on how to use the adaptor in the readme, it is not
>> at all polished and requires node.
>>
>> https://github.com/OokTech/TW5-PouchDBAdaptor
>>
> --
> 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/952167f3-cc7f-44a7-8093-629b2b3ef1a3%40googlegroups.com
> 
> .
>

-- 
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/CAJ1vdSTCypzZmZy_P%3DXnhxWFSJRXFknZ3EYt_LXrhnHi8B%2BVWA%40mail.gmail.com.

Re: [tw5] Re: Taking Node Server to the next level

[TiddlyTweeter]

TonyM wrote:
>
> I do have a possibly faulty distant memory of a tiddlywiki writing to a 
> Google sheet.
>

I *think* Mat did that ... hang-on ... 
yes: https://groups.google.com/d/msg/tiddlywiki/QcTOJCVXkDw/kS5VBW0ACQAJ

It uses Google Forms & Spreadsheets.

Best
TT

-- 
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/9cf5e7ef-0ab4-43c2-a1ee-5324b8d022ce%40googlegroups.com.

Re: [tw5] Re: Taking Node Server to the next level

[TonyM]

Jeremy

I do have a possibly faulty distant memory of a tiddlywiki writing to a Google 
sheet. I found it curious but it had no use case for me at the time. I will see 
if I can find anything.

We are spoilt for choice in some ways yet I feel we need to remove a few speed 
humps.

Regards
Tony 

-- 
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/d2cd70f7-c691-49c6-9687-7e98f3a315b7%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[mauloop]

Why not to reuse Tiddlyweb/Tiddlyspace work? 

   - It has MySQL backend
   - It is multiuser and allows concurrent editing
   - It has public and private spaces
   - It uses the standard Node.js sync-adaptor
   - It works with TWC as well

IMO it is a great piece of software. Not easy to set up. I did it on a 
local VM just to give it a try and Chris kindly helped me to solve some 
problems I fell into. I always feel bad when I see that good software falls 
into oblivion. Maybe it is not to be taken as is, but it could be a good 
starting point. Just to not reinvent the wheel.

Another thought is... this is an old paradigm. PMario's suggestion (DAT 
protocol) goes one step beyond, moving towards the p2p paradigm. I use 
Syncthing to keep my devices synced. Both (DAT and Syncthing, which, I 
think, uses QUIC behind the scenes) provides versioning, encryption and, 
last but not least, ... privacy!

TWedereation goes this direction too, isn't it?

I have no much developing skills to contribute, but I would be happy to 
help testing if needed.

)+(

-- 
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/cb3cdfd0-e05a-417a-a329-1281e2064ecb%40googlegroups.com.

Re: [tw5] Re: Taking Node Server to the next level

[Jeremy Ruston]

There have been quite a few experimental syncadaptors over the years. Some of 
them come back from a simple GitHub search:

https://github.com/search?q=syncadaptor

I went through the first couple of pages and found:

* an old syncadaptor for CouchDB: https://github.com/cjxgm/tearly/
* a syncadaptor for GitHub: https://ustuehler.github.io/tw5-github/ 
* another old syncadaptor for GitHub: 
https://github.com/kpe/tw5-github-syncadaptor/
* a syncadaptor for SoLID linked data stores (see https://solid.mit.edu/): 
https://github.com/linonetwo/solid-tiddlywiki-syncadaptor

Another syncadaptor that I'd love to see is one that stores tiddlers in an 
online Google Sheet. Done right, one would be able to seamlessly switch between 
editing the same data within TiddlyWiki and via the Google Sheet user interface.

Best wishes

Jeremy

--
Jeremy Ruston
jer...@jermolene.com
https://jermolene.com

> On 2 Dec 2019, at 07:29, Jed Carty  wrote:
> 
> 
> It is stored locally on the hard drive like other node wikis, the difference 
> is that this is stored in some database files instead of individual tiddler 
> files. It is not localStorage or a browser based solution.
> 
> If you use the browser based version of pouchdb it is generally built on top 
> of indexeddb or websql which are just localStorage. It doesn't have any 
> magical fixes and isn't any more persistent than the localstorage plugin. In 
> browser it is just localStorage with a slightly different interface and data 
> model on top of it.
> 
> To put this online you would end up just duplicating noteself I think.
> -- 
> 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/d406b178-989e-4c43-a9e4-a2efb476bdc2%40googlegroups.com.

-- 
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/171F0E9E-D679-45C2-BBD3-B73EE336DC33%40gmail.com.

[tw5] Re: Taking Node Server to the next level

[Jed Carty]

It is stored locally on the hard drive like other node wikis, the 
difference is that this is stored in some database files instead of 
individual tiddler files. It is not localStorage or a browser based 
solution.

If you use the browser based version of pouchdb it is generally built on 
top of indexeddb or websql which are just localStorage. It doesn't have any 
magical fixes and isn't any more persistent than the localstorage plugin. 
In browser it is just localStorage with a slightly different interface and 
data model on top of it.

To put this online you would end up just duplicating noteself I think.

-- 
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/d406b178-989e-4c43-a9e4-a2efb476bdc2%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[TonyM]

Jed,

Great work, what a Wiz. I will have a closer look. With the pouchDB have 
any more persistence that local storage I wonder?

Such node solutions are great but we must find an easy way to host such 
things online when needed.

Regards
Tony

On Monday, December 2, 2019 at 10:06:26 AM UTC+11, Jed Carty wrote:
>
> After finding out that I have very little idea how syncadaptors work I 
> started playing with making a new one and ended up with a working pouchdb 
> syncadaptor.
>
> It is very rough but it works, it will create a database and save tiddlers 
> to it, delete them when appropriate and then load the tiddlers when you 
> open it up again.
>
> At the moment the implementation is just for one wiki, but extending it to 
> have multiple wikis on the same node process would be very straight forward.
> It has potential for some things people have asked for like being able to 
> search all tiddlers in all available wikis.
>
> As a note, this is not noteself, while it could be configured to connect 
> to a remote database, either pouchdb or CouchDB, it doesn't have any of the 
> nice features of noteself other than saving to a database.
>
> Considering how straight froward this was making similar adaptors that 
> work with the various flavours of sql databases wouldn't be too hard aside 
> from figuring out the appropriate database schema. That is something I have 
> absolutely no interest in doing but this may work as a reasonable reference 
> design for anyone who wants to make a sql database adaptor.
>
> There are instructions on how to use the adaptor in the readme, it is not 
> at all polished and requires node.
>
> https://github.com/OokTech/TW5-PouchDBAdaptor
>

-- 
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/952167f3-cc7f-44a7-8093-629b2b3ef1a3%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[Jed Carty]

After finding out that I have very little idea how syncadaptors work I 
started playing with making a new one and ended up with a working pouchdb 
syncadaptor.

It is very rough but it works, it will create a database and save tiddlers 
to it, delete them when appropriate and then load the tiddlers when you 
open it up again.

At the moment the implementation is just for one wiki, but extending it to 
have multiple wikis on the same node process would be very straight forward.
It has potential for some things people have asked for like being able to 
search all tiddlers in all available wikis.

As a note, this is not noteself, while it could be configured to connect to 
a remote database, either pouchdb or CouchDB, it doesn't have any of the 
nice features of noteself other than saving to a database.

Considering how straight froward this was making similar adaptors that work 
with the various flavours of sql databases wouldn't be too hard aside from 
figuring out the appropriate database schema. That is something I have 
absolutely no interest in doing but this may work as a reasonable reference 
design for anyone who wants to make a sql database adaptor.

There are instructions on how to use the adaptor in the readme, it is not 
at all polished and requires node.

https://github.com/OokTech/TW5-PouchDBAdaptor

-- 
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/1da4eedb-510f-41a0-8394-d5322b79d73a%40googlegroups.com.

Re: [tw5] Re: Taking Node Server to the next level

[Arlen Beiler]

Most Node solutions that I am aware of are either request-based (AWS Lambda
and Cloudfront Workers), or VM based. There's also Heroku, but it doesn't
allow a persistent file system. However, the data storage structure is a
more serious bottleneck for innovation, I believe, and once we have a
working system, it's easier to move to the next step. The biggest thing I
see is the unpredictable nature of the file system as a predictable
per-tiddler storage system. While it is possible to load tiddlers from the
file system, I feel like some of the inherent drawbacks in this system are
preventing us from taking it to the next level.

Once we store tiddlers in a database, we can write an alternate server that
just stores client tiddlers straight to the database without going through
a $tw instance on the server. We'll still have use for the server to
bootstrap this system, but once setup, it can be fairly self-contained. In
that sense, perhaps taking the node server to the next level means becoming
smarter about the common use cases and writing software that can handle
them more efficiently. Not much has been done to make use of the server
itself -- most of the Node-side innovation is in other commands. The server
was recently rewritten to make it more flexible for server-based solutions,
which is useful. But I'm seeing a lot of client-side solutions that don't
need the server at all, except to store tiddlers and files.

In one sense it feels like a bit of a departure from the major
possibilities that the TiddlyWiki server presents. And for me that's a
little sad because I read source code and the TiddlyWiki server has
enormous potential to work along-side the TiddlyWiki client in the browser
for various solutions. But the general use-cases do not need this type of
functionality, and indeed are encumbered by it because I there is no good
way to tell whether a particular data folder needs the server-side
components or not.

Right now I could write a server using the filesystem adapter as my spec
that would serve data folders using Apache and PHP, but there is no good
way to tell whether any particular data folder might require the
server-side instance, so it has to be explicitly stated in some way, and
for that we need to come up with a new data folder format.

The data folder could be marked by the specific presence or absence of
certain plugins or other tiddlywiki.info properties, in order to properly
trigger an alternate format, but I think the best way would probably be
simply to add a property to tiddlywiki.info like "clientOnly": true. This
would allow existing data folders to be converted easily if the owner knows
it is safe to do so. It's not hard to implement this system with the
current data folders either, it just requires a similar amount of effort,
which may be necessary anyway.

So I guess that breaks this up into several parts.

   - First we need to "invent" client-only data folders and implement them.
   - Second, we need to attach a more robust storage system that isn't
   encumbered by the various file systems. This would allow us to implement
   multi-user and version control quite a bit easier.
   - Third, we need to implement this in PHP as an identical
   implementation.

I know it's a lot, but that's my summary of the what I'm seeing with what
we've discussed so far.

Arlen

On Fri, Nov 29, 2019 at 5:44 PM TonyM  wrote:

> Cont...
>
> Sorry. Mobile gg can be a pain.
>
> I understand Jed has done a lot of on securing bob when internet facing.
>
> So what I am asking is if node where more common on hosting and safe to
> open to the internet could we not focus on a smaller subset of technologies
> with similar outcomes?
>
> Of course we value a diversity of solutions.
>
> --
> 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/e7fd7b93-d44d-4de2-bbe5-63492ce18501%40googlegroups.com
> .
>

-- 
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/CAJ1vdSS3Z4J5asgfhG82aHK6%2BwRxVwR-kpH%3DvBuea%3DnBD2uBdg%40mail.gmail.com.

[tw5] Re: Taking Node Server to the next level

[TonyM]

Cont...

Sorry. Mobile gg can be a pain.

I understand Jed has done a lot of on securing bob when internet facing.

So what I am asking is if node where more common on hosting and safe to open to 
the internet could we not focus on a smaller subset of technologies with 
similar outcomes? 

Of course we value a diversity of solutions. 

-- 
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/e7fd7b93-d44d-4de2-bbe5-63492ce18501%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[TonyM]

Npm node etc... Is really easy to use locally and to serve to local area 
networks inside a firewall. However as pointed out by Jed this can be a 
liability on mobile computers joining other networks. This can be managed. My 
wholesale host let me install node internet facing but its not a documented 
service an

-- 
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/7f13a443-0d17-4942-ae70-aac8d18b3dfa%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

['Mark S.' via TiddlyWiki]

I was thinking of remote hosting and CPanel. I found there was pretty much 
no support for that or any easy equivalent.

But if it can be installed locally with NPM, then that could be interesting.

On Friday, November 29, 2019 at 10:54:14 AM UTC-8, Jed Carty wrote:
>
> Mark,
>
> The benefit of PouchDB is that it can be installed using NPM, or packaged 
> into something like BobEXE without having to do a system-wide installation. 
> For a local installation PouchDB is much easier to set up than 
> MySQL/MariaDb. If you didn't go the packaged route like BobEXE it would at 
> worst be cloning a repo and typing `npm install` to install the node 
> dependencies. Then you don't have to worry about setting up users or 
> anything on the databases, it is all self-contained.
>
> It is as easy to set up as sqlite, and if there are any MySQL/MariaDB 
> servers that are that easy to set up I would very much like to know because 
> every time I set up a database I forget how to do it and I have to look up 
> how to set up new users and permissions all over again.
>
> On a remote server it would be at most one extra command when installing 
> node and tiddlywiki, and that is only if we don't have an install script 
> set up.
>
> If you want something larger on a remote server, CouchDB has the same 
> interface as pouchdb and is as easy to set up as MySQL/MariaDB in my 
> experience.
>
> I don't know if many hosting providers give out of the box CouchDB 
> installations, so that may be a problem, but I think that anyone in a 
> situation to need something that heavy duty would be experienced enough to 
> not have trouble with it.
>

-- 
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/b26dd2b8-bc71-4502-bded-51bfbe088b91%40googlegroups.com.

Re: [tw5] Re: Taking Node Server to the next level

[Arlen Beiler]

I'm kind of thinking that if the user is setting up MySQL themselves, then
they have control of the server and might as well be setting up
TiddlyServer or Bob anyway, unless MySQL is up their alley, in which case
it's no big deal. On the flip side, using PouchDB or SQLite instead of the
file system would allow some more advanced solutions such as multi-user
editing and version control to be built in much easier.

I'm hoping eventually to find a way to host wikis in TiddlyServer without
using the Node server instance, since it does consume a certain amount of
memory per wiki, and this is one step in that direction. Once that is
accomplished we could transparently write a PHP version of TiddlyServer
that could be used on any shared hosting. Once that happens TiddlyWiki
could become a serious contender as a self-hosted multi-user wiki.

But since my paradigm is to operate within the constrains of current
TiddlyWiki code, I have to take it one step at a time.

On Fri, Nov 29, 2019 at 1:54 PM Jed Carty  wrote:

> Mark,
>
> The benefit of PouchDB is that it can be installed using NPM, or packaged
> into something like BobEXE without having to do a system-wide installation.
> For a local installation PouchDB is much easier to set up than
> MySQL/MariaDb. If you didn't go the packaged route like BobEXE it would at
> worst be cloning a repo and typing `npm install` to install the node
> dependencies. Then you don't have to worry about setting up users or
> anything on the databases, it is all self-contained.
>
> It is as easy to set up as sqlite, and if there are any MySQL/MariaDB
> servers that are that easy to set up I would very much like to know because
> every time I set up a database I forget how to do it and I have to look up
> how to set up new users and permissions all over again.
>
> On a remote server it would be at most one extra command when installing
> node and tiddlywiki, and that is only if we don't have an install script
> set up.
>
> If you want something larger on a remote server, CouchDB has the same
> interface as pouchdb and is as easy to set up as MySQL/MariaDB in my
> experience.
>
> I don't know if many hosting providers give out of the box CouchDB
> installations, so that may be a problem, but I think that anyone in a
> situation to need something that heavy duty would be experienced enough to
> not have trouble with it.
>
> --
> 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/1fb383cf-b1d0-4cd0-9768-a6f315076b53%40googlegroups.com
> 
> .
>

-- 
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/CAJ1vdSQUnaOTbruvDuwADqBsC__epJMJyLGY-Ujqxh2pTakM8A%40mail.gmail.com.

[tw5] Re: Taking Node Server to the next level

[Jed Carty]

Mark,

The benefit of PouchDB is that it can be installed using NPM, or packaged 
into something like BobEXE without having to do a system-wide installation. 
For a local installation PouchDB is much easier to set up than 
MySQL/MariaDb. If you didn't go the packaged route like BobEXE it would at 
worst be cloning a repo and typing `npm install` to install the node 
dependencies. Then you don't have to worry about setting up users or 
anything on the databases, it is all self-contained.

It is as easy to set up as sqlite, and if there are any MySQL/MariaDB 
servers that are that easy to set up I would very much like to know because 
every time I set up a database I forget how to do it and I have to look up 
how to set up new users and permissions all over again.

On a remote server it would be at most one extra command when installing 
node and tiddlywiki, and that is only if we don't have an install script 
set up.

If you want something larger on a remote server, CouchDB has the same 
interface as pouchdb and is as easy to set up as MySQL/MariaDB in my 
experience.

I don't know if many hosting providers give out of the box CouchDB 
installations, so that may be a problem, but I think that anyone in a 
situation to need something that heavy duty would be experienced enough to 
not have trouble with it.

-- 
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/1fb383cf-b1d0-4cd0-9768-a6f315076b53%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

['Mark S.' via TiddlyWiki]

The problem with solutions like PouchDb is that there are no turn-key 
installations. You have to pretty much do everything yourself down to the 
bare metal.

SQL, on the other hand, is supported almost everywhere.

The workaround re fields is to specify the fields you want in advance. 
Rebuild the database when you need to add fields.

Or to have a dozen fields with generic names in the database, but then map 
them with a configuration file.

Mostly, I'm saying that a solution that is for everyone needs to based on 
technology that's commonly available.

Of course, there's nothing to prevent someone from creating cool stuff, 
just because.


-- 
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/92975eba-bd46-43d3-83c4-68be96fde807%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[PMario]

On Friday, November 29, 2019 at 12:45:17 PM UTC+1, Jed Carty wrote:
...

> Running a ArangoDB for hosting peoples tiddlywiki like tiddlyspot would 
> probably work well, I am less certain about local installations.
>

You are on the point. I do have similar concerns about every database ... 
They store the info in "hidden" places. I think our users want files, 
somewhere in the workflow. 

That's why I'm so interested in the peer-to-peer approach of the 
dat-project. I think the "file-system" they use has a lot of functions 
built in, that we want to have for TW. _and_ at the end the binary 
data-store can be mapped to real files. 

What's the videos. All of them and you will see, what I mean. 

-m

-- 
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/df23f044-4436-448c-af2c-dd0bf1132d37%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[Jed Carty]

ArangoDB looks very interesting as an option. I haven't run into any 
multi-modal databases like that before.

It does look like the data model is just about ideal for tiddlywiki in 
terms of storing tiddlers and full html files, storing html files as a 
string shouldn't be a problem. A quick glance didn't show any binary data 
storage for media attachments, but base64 encoding should work there.

My only concern with ArangoDB is that it looks like it is a system wide 
install instead of specific to the process running it, leveldb (and by 
extension pouchdb) don't require additional installation to function.

Running a ArangoDB for hosting peoples tiddlywiki like tiddlyspot would 
probably work well, I am less certain about local installations.

-- 
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/401cf625-b2e7-4c94-b08a-b05f0e0b2c5f%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[PMario]

One more thing: 

 - The cool thing about DAT is, that it will nicely run on a raspberry pi 
3, with a big harddrive attached. 

-m

-- 
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/39338b32-fa22-495a-9859-eb276bd7ee7d%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[PMario]

Some more thoughts.

The problem with databases I see are: 

 - *Our users like files* and will go a long way to keep it that way. 
 - DBs need maintenence
 - DBs need to be secured
 - ... 

So in the end we need a service provider, that abstracts the complexity 
away. 

I personally would like to use a dat-project based approach, which is 
similar to a "file sync" mechanism. ... The beaker-browser uses dat as its 
foundation. 

PROBLEM here is: 

 - It's a young project with contains some fast moving targets. 

If you have a closer look at the dev-diary videos 
,
 
I think you can see, how nicely the "new" approaches would fit to 
tiddler-based TWs. 

 - Concepts show in the videos can only be *tested, if you compile the 
developers branch on your own*. 

have fun!
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/ad7180ba-e4d6-4d19-bd25-578cf4842391%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[PMario]

Hi, 
If you would want to have a cool new database ArangoDB may be an option. 

ArangoDB is the open-source native multi-model 
> database for graph, document, key/value and search needs.


So we could store tiddlers as "documents" and add some graph info to create 
a "map" like structure. 

It also contains a JS framework named Foxx 
: 

Foxx is a JavaScript framework for writing data-centric HTTP microservices 
> that run directly inside of ArangoDB.


So the nodejs stuff could directly run inside the database. The only thing 
we would need to define is a consistent API. 

Just some thoughts. 

-m

-- 
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/f1d48cb4-683c-4b5e-85eb-21a042fa61cc%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[Jed Carty]

A while ago I made a syncer that used sqlite and from that I wouldn't 
suggest a relational database, SQL seems like it would be almost perfect 
for storing tiddlers but I immediately ran into problems with the database 
schema because aside from text, title, tags, created, type and modified you 
have on way of knowing what fields are going to be used so everything else 
just gets thrown into an otherfields column and you lose the desirable 
features of a relational database.

I found pouchdb to work much better because you can have arbitrary 
structures in the documents and implement the tiddlywiki filters pretty 
exactly in calls to allDocs and as a document store it can store single 
file wikis without any trouble at all.
I have been considering skipping pouchdb and just using leveldb directly on 
the back-end but I don't know if the performance improvements are worth the 
extra hassle.

Also in pouchdb you just make a new database for each wiki and never run 
into problems of scale except in the most extreme cases. I have had pouchdb 
databases that were close to a gig without any real performance hit, I 
think that wikis anywhere near that size are going to be rare.

I have looked into other nosql databases and none of them look like they 
would be any better than pouchdb or using leveldb with some basic 
namespaced storage setup.

also in my experience database maintenance is much easier in pouchdb and 
leveldb than in MySQL/MariaDB. You don't have the same problems of having 
database files taking up 100gigs when you only have 4 gigs of data that 
changes often. I am sure that problem can be solved by having an 
experienced database maintenance person, but I think that with one of the 
nosql  databases you could skip that completely.

-- 
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/c17d001b-1967-421b-abb4-743869a44bfc%40googlegroups.com.

[tw5] Re: Taking Node Server to the next level

[TonyM]

Arlen,

I would think this a great idea. SQLite, MariaDB etc... could be used. I 
use a cpanel account on a hosting service and often jump in behind the 
scenes to manipulate databases. It would be quite easy to define additional 
databases with an sql script designed for Tiddlers or TiddlyWikis.

In the spirit of  brainstorming.The vast majority of my ideas may be 
implemented in tiddlywiki itself with SQL only the underlying database.

The ease of securing online hosting for SQL databases would be a big plus 
as it is less onerous than the lesser available databases like CouchDB.

Of course in time it would be good if we can ensure an editor at a time, or 
multi-user access to such a tiddlywiki database but simple single edit 
(Multiple read/Public) user implementations would be valuable. I believe a 
lot of control can be designed into this at the tiddlywiki level, just 
using the database as storage, tiddler at a time. Backend database tools 
could also clone wikis etc... and if we could get such an implementation 
script into installatron, softaliciouse etc... more people would discover 
tiddlywiki.

The ability to store tiddlers in a sql database could be handled more than 
one way.

   - Allow an online readlony hosted wiki to connect to a database and with 
   the right credentials save changes to tiddlers in an sql database and 
   reload them as needed somewhat like Browser local storage does.
   - Store all of the wiki in a database. Or perhaps with the javascript or 
   core in a file to help launch the wiki.
   - I believe there is a possibility for users to easily install SQL DB's 
   they can connect to locally (Device or LAN) and overcome the limitations of 
   browser local storage with trusted persistent storage (We can possible find 
   multiple OS installs for this).
   - One minimal tiddlywiki could be configured to connect to more than one 
   database, but one at a time, so the user or designer selects which database 
   they are using (Like CouchDB), thus each user could perhaps have their own 
   version of a tiddlywiki.

I think however we need to ensure that a full wiki single file wiki can 
still be exported and ideally one imported into a database. Perhaps we 
could generate an SQL script from a living tiddlywiki and run that in 
PHPAdmin to build the database, then such scripts could be generated for 
various editions.

One big advantage with SQL is there will be new opportunities for 
integration with other systems. Other systems could submit tiddlers to the 
database or query the database to interact with tiddlywiki. This 
integration includes between tiddlywikis, eg same database different 
tables/wikis and some primitives to use the other wiks tiddlers.

Since I have investigated the development of a community resource website I 
have fancied building a WordPress site and having tiddlers in one or more 
wiki tables but with the ability to access content from the wikis in 
WordPress and Visa Versa, such as plugin and macro code and more. This 
would allow us to build a meta community site that can handle all the 
different TiddlyWiki objects, plugins, macros, editions, documentation 
submissions and discussions and more. I have toyed with new post types that 
allow people to submit content such as a plugin via a custom wordpress post 
that can then be dropped on a wiki. Buy doing this we can categorize sort, 
file, discuss  Making us of WordPresses multi-user and OpenID and Auth 
systems over multiple tiddlywiki resources.

*I would be quite prepared to test, participate and feed back on any such 
project. To me this could be the mainstreaming of tiddlywiki.*

Regards
Tony

On Friday, November 29, 2019 at 10:59:43 AM UTC+11, Arlen Beiler wrote:
>
> I have a radical proposal which would take data folders to the next level. 
> What if instead of the file system adapter we would write a new adapter to 
> use a database. We could use PouchDB, but I would vote for something much 
> more widespread like SQLite. We could also write it in a generic way that 
> makes it easy to use with the regular SQL databases. It would be easy to 
> build but I would want to make it robust enough to use in a wide array of 
> platforms. 
>
> I have already worked with the tiddler loading code enough to be certain 
> it is self contained and can easily be made asynchronous to accommodate 
> this feature. Or the preload tiddlers feature can be used, but I think it’s 
> better to separate out the loaders as Jeremy has mentioned. 
>
> Any thoughts on this or things I should keep in mind as I brainstorm? 
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/37c23496-e987-4ccf-939a-98177ccb01cf%40googlegroups.com.