I've added a ticket for properly enabling external images with the
client-server configuration:

https://github.com/Jermolene/TiddlyWiki5/issues/1000

(yay! 1,000 bugs!)

The other route you may be able to explore at the moment is to use the
existing lazy image support, along with caching the .html file in nginx.

Best wishes

Jeremy.



On Tue, Oct 21, 2014 at 8:55 AM, PMario <[email protected]> wrote:

> On Tuesday, October 21, 2014 12:03:59 AM UTC+2, Rick Williams wrote:
>>
>> Did you do the import step? So import the small index.html into the
>> server.
>> You could select all. ... You did a backup right?
>>
>>        I did do this later. But I still winder if it was really
>> necessary. The image files were already in the images directory.
>>
>
> Yes, the images are in the image directory already. But the server version
> doesn't know about it.
> The whole build step creates the index.html file.
> It creates the images
> It changes the image tiddlers (_canonical_uri, empty text)
> ... but it doesn't touch the image.png.tid or .jpg.tid files.
>
> So they are still big. If the server starts, it still uses those files.
>
> If the server is started and the index.html is imported, the .png.tid
> files are small.
> So it seemed to work right in your configuration according to the "ls
> tiddlers/" ouput.
>
>
>
>> Tiddlywiki server doesn't use the "build" info. So it doesn't know about
>> the images directory to store new images.
>> The TW server at the moment is a very very basic server to make TW
>> development easier.
>>
>>       OK, I see. Does this mean I need to rerun the 'build' step
>> periodically to get new image files placed in the right directory?
>>
>
> hmmm, That's why I wrote:
>
> I'm not sure, what happens if you do the build several times.
>> If the tiddlers already have the _canonical_uri ... So take care.
>>
>
> Since the (small) images are still tagged with "external-image", they are
> touched everytime you run the build.
> So you need to check if everything is right after a new build run. .... I
> just didn't test this case, so I don't know.
>
> Also the import step is needed every time you did import images with the
> TW drag and drop action.
> The TW binary file handling isn't optimized for this workflow at the
> moment.
>
> So an alternative version would be to let nginx handle the file upload.
> I did a fast search and found this: https://coderwall.com/p/swgfvw
> I did a search:
> https://www.google.at/search?q=file+upload+ui+for+nginx&tbs=qdr:y
> and found:
> http://www.howtoforge.com/displaying-upload-progress-with-nginx-on-debian-wheezy
>
> If nginx does the upload handling, there is the problem, that we need to
> tell TW about the new file. ....
>
> ... As I wrote. The workflow needs to be improved for binary file handling.
>
>
>       It also brings up another question about the future plans for the
>> system. Do you indeed plan to have a more robust server implementation?
>>
>
> I need to pass this on on to @Jeremy.
>
>
>> After all, the value is in the sharing of information among many. I have
>> no use for a "personal" wiki.
>>
>
> One reason, that makes TiddlyWiki special and unique, is its focus on
> beeing an all-in-one single file Wiki. But for your configuration, this is
> actually a weak spot.
>
> You are right, _one_ value of a wiki is in sharing it :) And there are
> plenty of requests, in making the sharing easier.
> But most TW users _don't_ want to touch a server. They request file based
> sharing options. ...
>
> But in the TW hangouts we discussed making server more robust.
> There is a hangout today:
> https://plus.google.com/u/0/events/cd8h7qbbtethtk44i98cq2fmmis
>
> There is a very robust backend for TiddlyWiki. It's called TiddlyWeb. It's
> a python app, with a lot of options.
> In its basic configuration it uses a similar file based store as the TW
> node server.
> If you are python guru it should be relatively easy for you to handle it.
> If not, it can be overwhelming.
>
> Can you describe your usecase a bit closer, if that's possible.
> So I can see, if I should recommend it, or not :)
>
>  - How many different wiki's do you need?
>  - How many users?
>  - Do you have many different editors?
>    - or just consumers with a view content editors / creators?
>
> -----------------
>
> There is still the option, to create a completely static version of all
> tiddlers, no javascript involved.
> This could be served entirely by the nginx server.
> So every tiddler is a single page. .... There would be the need for a
> different layout, because at the moment the static version uses the same
> layout as the js version.
>
>
> Thanks again for your help.
>>
>
> you are welcome
>
>
>>
>> The load time is still pretty slow - 38 seconds or so. It does take
>> pretty long over the network to serve the data. I'm turning my attention
>> now to speeding that up. I have a NAT in the way that I maybe can avoid.
>>
>
> ok, let us know if it worked out.
> Thx for posting your nginx configurations, it will help others, that want
> to use TW with a similar configuration.
>
> have fun!
> mario
>
>



-- 
Jeremy Ruston
mailto:[email protected]

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

Reply via email to