TW too big
Oscar
I use TW like a blog and I like it; but there is a problem: after one
year it growed its size and now it's near to 1MB; someone of my
readers has not a broadband, and opening my blog seems more hard any
day that passes.
I wouldn't change my blog to a common platform like wordpress or
blogger; but I'm searching a TW-based engine that works better for
blogging.
I saw that exist cctiddlywiki, phptiddlywiki and other platforms.
Do you know wich one is the simplest, fast and that permitt me to
import my posts and that supports plugins?
Thank you very much and pass a good Easter (or a good week-end,
anyway :-) )
Oscar
http://corax.altervista.org
jroeterd
Greetings,
Jar
google....@dfgh.net
CC
Ken Girard
#IncludePlugin).
It lets you 'include' tiddlers from other TWs by loading them
temporarily into your main TW.
An example would be to move all the tiddlers from the first 6 months
of your blog and put them in a different TW. The include plugin then
loads them later in the process, so that a visitor gets to see
something faster.
The one thing that I noticed doesn't work well is permalink as it
tries to open the tiddler before the tiddler is actually loaded.
Also, great looking TW.
Ken Girard
FND
> #IncludePlugin).
> It lets you 'include' tiddlers from other TWs by loading them
> temporarily into your main TW.
But IncludePlugin doesn't support load on demand (yet?) as far as I know.
That is, if include tiddlers from another TW, it will always load them
with the core TW, which results in the same filesize and loading time.
I might be wrong though... !?
-- F.
Udo Borkowski
That is, if include tiddlers from another TW, it will always load them
with the core TW, which results in the same filesize and loading time.
<<include "file://C:/Private/journals/2006-12.html" delay: 8000 >>In this case the file is included 8000 ms (8 seconds) after TiddlyWiki is loaded. So the user can already start working with TiddlyWiki after the (smaller) core TW is loaded. After a while other files will access become available.
Another advantage of the include feature is: "Saving" gets faster since only the (smaller) core TW file needs to be saved after a change.
Udo
Oscar
I'll try to use the includePlugin.
Fingers crossed ;-)
On Apr 9, 10:48 am, "Udo Borkowski" <udo.borkow...@googlemail.com>
wrote:
> > That is, if include tiddlers from another TW, it will always load them
> > with the core TW, which results in the same filesize and loading time.
>
> > If you add the filesize of the core TW and the included TW you will get
>
> roughly the same filesize as the "big one". If you add the load and include
> time you will also get the same time, possibly even a little more. But you
> may make it "feel faster" by using the "delay:" parameter
>
> <<include "file://C:/Private/journals/2006-12.html" delay: 8000 >>
>
> In this case the file is included 8000 ms (8 seconds) after TiddlyWiki is
> loaded. So the user can already start working with TiddlyWiki after the
> (smaller) core TW is loaded. After a while other files will access become
> available.
>
> Another advantage of the include feature is: "Saving" gets faster since only
> the (smaller) core TW file needs to be saved after a change.
>
> Udo
>
FND
Good point, Udo - I hadn't thought of that!
> Another advantage of the include feature is: "Saving" gets faster since
> only the (smaller) core TW file needs to be saved after a change.
True - especially since it's unlikely that Oscar will retroactively
change any of the older blog entries, which aren't stored in the core
TW. (Other, less-linear/chronological TWs might be more problematic.)
While we're at it though: Is there any chance that load-on-demand
features will be available sometime in the foreseeable future? Or would
that require major changes in the TW core code?
-- F.
Udo Borkowski
Also: because of the current user interface (especially the "sidebar") this "load on demand" will probably happen fairly quickly after startup (for nearly every tiddler). E.g. if the "Timeline" tab is open at least all titles, modifiers, mod-dates of tiddlers must be loaded immediately. When the "Tags" tab is selected, all tiddlers' tags must be loaded and for tabs like "Orphans" or "Missing" the complete tiddlers (esp. its texts and titles) must be loaded to check for orphan or missing tiddlers.
Udo
----------
Udo Borkowski
http://www.abego-software.de
FND
> because of the internal structure of TiddlyWiki.
I see - thanks for clearing that up.
(+5 Insightful: 70% Insightful, 30% Interesting ;) )
-- F.
Andrew Lister
opinion since the comments by Martin and Jeremy in this thread, from
Mar. 7, 8:
Has there been a change, or is there just some uncertainty or
disagreement about how things will / should evolve, or did I misread
those original posts?
Andrew
Jeremy Ruston
The new feature is kicks in when a link to a missing tiddler is
clicked. If the tiddler hosting the link is synced to a particular
server, then an attempt is made to asynchronously load the missing
tiddler from that server. There is also a mechanism to allow missing
tiddlers to be resolved when the host tiddler isn't synced.
One usage scenario is to pull in a single article from Wikipedia.
Clicking on links to other Wikipedia articles will cause the target
article to be automatically loaded.
Right now, the mechanism isn't super efficient in some scenarios - for
instance, if you use it to load tiddlers from an ordinary TiddlyWiki
file (whether loaded from file:// or http://), then the file is
reloaded afresh each time a missing tiddler is resolved. We'll get
that sorted out though.
Cheers
Jeremy.
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Udo Borkowski
When I talk about "load on demand" I have in mind the vision a user should not see any difference between "normal" tiddlers and "load on demand" tiddlers (beside some delay when a tiddler is loaded "on demand"). E.g. a link to a "load on demand" tiddler should look like a normal link and not like a "missing" tiddler link. The "Timeline" should contain both kinds of tiddlers, a search should also return "load on demand" tiddlers etc.. I assume such a "seemless integration" of "load on demand" will require a lot of work and is beyond the scope of TW 2.2 (and even 2.3, I guess)
Nevertheless your new mechanism is definitely a great way to make TiddlyWiki files smaller and shorten initial load times. Looking forward to see the first applications.
Jeremy Ruston
populations of tiddlers, and of course that constraint makes it
impractical to do the 'phantom tiddler' approach that we've discussed
before.
Cheers
Jeremy.
Andrew Lister
further question. I can see, intuitively, that load-on-demand for
links to missing tiddlers can accommodate an arbitrarily large number
of such tiddlers, because no information about the tiddler is loaded
until the missing link is clicked. In contrast, the 'phantom tiddler'
approach involves loading all of the metadata (tags, modification
date, etc.) for all tiddlers in advance, and then the body only on
demand. Still, would the phantom tiddler approach not permit largER
documents than are currently feasible? I suppose it depends on how
load-time works. If it's a linear function of the number of
characters, say, then not having to load the body of the tiddler could
be a big time saving, if each tiddler typically contains a good-size
paragraph. On the other hand, if there is significant overhead load-
time for each field, and the tiddler body is just one extra field, and
the size of the tiddler body isn't that important, then loading the
body on demand won't make a big difference.
My reason for wanting to understand this issue, and the likely course
of future developments, is that I am interested in being able to
accommodate large but not indefinitely large amounts of tiddlers and
text.
Jeremy Ruston
mechanism to cover the phantom tiddler scenarios. The idea would be
precisely as you say: to be able to preload the metadata for a bunch
of tiddlers whose actual content is only loaded when needed.
Internally, the feature would be based on the convention that if the
'text' property of a Tiddler object were undefined, then the tiddler
would be either unloaded or in the process of being loaded, with a
further member 'loadStatus' tracking the precise loading status of the
tiddler.
On an attempt to display a tiddler that hasn't yet been loaded, an
asynchronous task would be kicked off to load the necessary data from
the server.
This is a slightly different approach than that proposed by Udo
earlier in this thread, because it requires code that access the
'text' property of tiddlers to be aware of the new behaviour. At first
sight, it seems that if we had enforced access to the 'text' property
via an accessor method, we could have seamlessly upgraded to the new
behaviour. Sadly, in practice, the new behaviour is asynchronous and
it is not in general possible or desirable to change an existing
synchronous function to asynchronous behaviour without breaking
dependent code.
Cheers
Jeremy
Oscar
Now I'm in a testing phase, but it seem working.
Some little problem with permalink; but I think you resolved my
problem.
Thanmk you very much to all!
On 9 Apr, 10:48, "Udo Borkowski" <udo.borkow...@googlemail.com> wrote:
> > That is, if include tiddlers from another TW, it will always load them
> > with the core TW, which results in the same filesize and loading time.
>
> > If you add the filesize of the core TW and the included TW you will get
>
> roughly the same filesize as the "big one". If you add the load and include
> time you will also get the same time, possibly even a little more. But you
> may make it "feel faster" by using the "delay:" parameter
>
> <<include "file://C:/Private/journals/2006-12.html" delay: 8000 >>
>
> In this case the file is included 8000 ms (8 seconds) after TiddlyWiki is
> loaded. So the user can already start working with TiddlyWiki after the
> (smaller) core TW is loaded. After a while other files will access become
> available.
>
> Another advantage of the include feature is: "Saving" gets faster since only
> the (smaller) core TW file needs to be saved after a change.
>
> Udo
>