On Jan 14, 3:09 pm, "Simon Baird" <[email protected]> wrote:

> Look, you're not being selfish. Cookies are a bad idea for config.
> CookieSaver is a kludge to get around this and make TW config a little more
> bearable. I dream of the day when you can configure a TW in a sane way.

Maybe kludge isn't the right word as Eric doesn't do kludges, rather
it's making do with what you have and trying to be loyal to the
TiddlyWiki core, such as it is, as much as possible.  However it does
represent a lot of overhead for something better fixed in the core to
start with.

I suggested in one of the links Simon points to was a type of *.ini
file that does travel with a TiddlyWiki and is specific to only that
TiddlyWiki.  I see that while a TiddlyWiki is made up of modules, a
TiddlyWiki itself can be considered as a module in yet a bigger
system.  Therefore they must not interfere with one another in any
way.

I gazed at the core today with glazed eyes wondering if there was a
way add a suffix to the cookies to make them specific to each
TiddlyWiki.  That would solve a lot of the problems, but possible
create more.

Scrolling through I realized how many cookies are used in plugins
which is another issue to consider for any changes since the core
cookies can actually be a smaller part of the whole picture.

Cookies are, after all, a browser tool and what we really want for
most things is an *.ini file that has served so many applications for
so long.  How this translates to TiddlyWiki is a matter of semantics.
I do agree with Eric that more specialized TiddlyWiki code shouldn't
be created for this as it creates too much inbreeding and will
eventually lead to a cul de sac sooner or later.

If there exists as, Simon says, a patch that we can try then what
better experiments could we do than for some of us to actually try it
and let it evolve.

Notwithstanding all of the above; the question of the massive
investment in plugins must be faced. How will any changes affect them?

Morris



On Jan 14, 3:09 pm, "Simon Baird" <[email protected]> wrote:
> Look, you're not being selfish. Cookies are a bad idea for config.
> CookieSaver is a kludge to get around this and make TW config a little more
> bearable. I dream of the day when you can configure a TW in a sane way.
>
> More discussion on this topic 
> here:http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/694...
>
> A patch here:http://trac.tiddlywiki.org/ticket/756
>
>
>
> On Wed, Jan 14, 2009 at 1:55 PM, Matt L. <[email protected]> wrote:
>
> > Thanks for the info, Eric!  I freely admit that I use TW strictly for
> > my own information store and thus did not even consider those who use
> > TW as a website or to share information with others.  I guess that
> > (being selfish) I wish the default action was for TW to store settings
> > internally, and only write to cookies if that option is enabled.  I
> > suppose I look at TW as being designed primarily as a portable data
> > application that just so happens to function as a website and/or
> > sharing tool - not the other way around.  As a portable application,
> > saving to cookies makes TW much less portable, since each new computer
> > you take it to would use the default settings...  In order for it to
> > be truly portable, you have to use a cookie plugin or carry your
> > browser around along with your TW file (which I do - but that isn't
> > the point!).  I guess it is six-of-one/half-dozen-of-the-other - and
> > my preferences happen to lie with the "other"...  :-)
>
> > I will check out the CookieSaver plugin, though - that sounds like it
> > would be quite useful.
>
> > Thanks again!
> >  - Matt L.
>
> > On Jan 13, 6:17 pm, Eric Shulman <[email protected]> wrote:
> > > > I would say that having the default behavior save the config data to
> > > > the cookie is an annoyance.  I wish the default value of TW and all
> > > > plugins was to save to the config tiddler - only those who choose to
> > > > use the cookie method should do that.  It would make TW much more
> > > > portable out-of-the-box.
>
> > > Saving settings to a 'configuration tiddler' instead of cookies
> > > produces a different semantic: instead of associating the settings
> > > with a given user/browser, the settings will be tied to the document.
> > > if you are creating private documents that you never share with
> > > others, this doesn't make much difference.
>
> > > However, if you are publishing your document, then you need to be very
> > > careful that any tiddler-based settings don't contain 'secret' data
> > > (such as passwords, private URLs, local paths, etc.).  This is one
> > > advantage of cookies: they are guaranteed never to be revealed to
> > > others... while document-based settings would be immediately visible
> > > and *applied* to everyone that accesses the published document.
>
> > > In addition, document-based settings won't permit variations in
> > > personal preferences that vary from user to user (such as enabling/
> > > disabling animations, incremental searching, etc.), as well as
> > > stateful information (like the open/closed condition of specific
> > > sliders).
>
> > > While these settings *can* always be changed during a session, without
> > > cookies, those changes don't persist to the next session.  This can be
> > > especially problematic when setting the desired username (in the
> > > Sidebar options).  Without cookies, every time you reload the
> > > document, the usename would revert to either the tiddler-based stored
> > > value (if any) or the built-in default "YourName".
>
> > > Nonetheless, despite these differences in semantics, there *are* quite
> > > a few settings that might be reasonably handled using document-based
> > > storage.  As you noted, however, such stored is *not* part of the
> > > standard TW distro... but it IS available as an optional component:
>
> >http://www.TiddlyTools.com/#CookieManagerPluginhttp://www.TiddlyTools...
>
> > > CookieManagerPlugin lets you review/set/delete individual cookie-based
> > > TW settings, as well as "bake cookies" to generate a static
> > > [[CookieJar]] tiddler containing a snapshot of those cookies (or "bake
> > > options" to create a snapshot of *all* current option settings, even
> > > if they don't have a corresponding cookie).
>
> > > CookieSaverPlugin extends this handling to capture cookie-based
> > > settings as they occur and automatically write them to the
> > > [[CookieJar]].
>
> > > enjoy,
> > > -e
> > > Eric Shulman
> > > TiddlyTools / ELS Design Studios
>
> --
> [email protected]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/TiddlyWiki?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to