[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
Thanks for all the comments everybody. I'm just working my way through them and will post replies later today. Martin On Nov 20, 3:19 pm, whatever kbrezov...@gmail.com wrote: Well, as long as it's not a bug. Though, as far as I know we're still in November, not in December. :D w On Nov 20, 3:40 pm, Jeremy Ruston jeremy.rus...@gmail.com wrote: Also, considering that TW already has a backstage mechanism for setting options (Tweak and/or Options from AdvancedOptionsPlugin (1)), it would be nice if such a mechanism were enabled for SystemSettings. It could be added as a tab to existing options, where you could add a tick to make it cookie dependent and/or set the actual default value. We stopped short of adding a user interface for switching options between cookie vs. baked settings to keep things simple at first, but it certainly seems a reasonable idea. I was just checking out the beta and I noticed that dates seem to be all out of whack. For example,http://tiddlywiki.com/beta/#PersistentOptions shows date modified 20 December 2010 andhttp://tiddlywiki.com/beta/#HelloThere shows date modified 15 December 2008 (possible, but unlikely, considering the content). I think that is just because the content was authored in a text editor, and not the full TiddlyWiki environment, and those tiddlers inherited the wrong dates through a slip of cut and paste. Cheers Jeremy w On Nov 19, 12:53 pm, Ton van Rooijen tons...@xs4all.nl wrote: This is a very nice enhancement indeed. The syntax however is i.m.h.o. somewhat confusing. Why append the option-name with _cookie:? a) to me it looks like an unnecessary complication of the syntax. b) the syntax more or less suggests (because of the closing colon) that you could still provide a value, which is illogical. So why not simply stick to the original syntax of option-name: value or option-name=value in which value can be cookie, true, false or a real value (like e.g. in txtUserName). W.r.t. the discussion about the preference: cookie vs SystemSettings I would like to suggest 2 possible solutions. Either: SystemSettings take preference when viewed over HTTP, whilst when opened from a local file the cookies take preference. This gives maximum control for the author/owner. Or: The SystemSettings enhancement is even further enhanced by being able to have 2 sets of system-settings: one options-set for viewing over HTTP and one for local use from a file. I fully support the earlier suggestions from AlanBCohen and whatever, to make cookies dependent on the filename of the TW-file. So every TW-file gets its own cookies. P.S. This whole contribution is written based on experience with independent TWs; I have no knowledge of or experience with TiddlySpace. Thanks to all involved for again having a great TW release. On 18 nov, 14:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
We'll certainly give consideration to the suggestion of using the filename as part of the cookie id, but not as part of the 2.6.2 release - it's too large a piece of work to slip in at the end of the release cycle. However, the baked cookies do offer a solution to your problem - the UserName has been set as a persistent option, so it can be different for different TiddlyWiki files. Any cookie that you do not want to be used in multiple files you can set as a persistent option. This does rely on persistent option taking precedence over the cookie (as in the current beta) - which goes against your preference of having the cookie take precedence. Martin On Nov 19, 3:10 am, AlanBCohen alanbco...@gmail.com wrote: My suggestion would be that as part of the implementation of persistent (Baked) cookies, consideration be given to including the current file name as part of the cookie ids. I realize not everyone uses multiple open TW files at the same time, but the many uses of cookies in TW currently means that the same cookies are affecting multiple files. I may well want my sidebar hidden in one file but want it open in another. I often use separate TW files to keep separate what would otherwise be one large, slow file, at work, for example, my addressbook, my work diary, my primary collection of links, and my collections of technology notes. Even the username might vary between someone's personal files and a team-based TW file. I'm reasonably sure there would be others with similar needs for distinct cookies between TW files. My suggestion on precedence for identically named cookies would be for the persistent ones to be of lower priority than the session cookies. This would allow the same values at start as were valid at the beginning of the previous session (if the persistent cookies in the tiddlers were not changed and saved during that session) while allowing them to be changed for the session. -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
Ton, the reason for the current syntax is that it is conceivable that someone might want to use the value cookie as an option. (Here's a stupid example: someone might have the nickname cookie, which they might want to set as their username.) I know this is somewhat contrived, but there is also the issue of future features to consider: suppose, in future, we wanted to add a new way of controlling options (say default) - we'd run the risk of breaking any TiddlyWiki that had an option string set to default. I'm not sure what I think about having different precedence for local and http viewing - this could cause problems for someone who has a TiddlyWiki that they have exported from TiddlySpace - having different online and offline options could be very confusing. Likewise having two sets of options, one for online and one for offline. I'm not dismissing this out of hand, but I will need to think about the consequences. Martin On Nov 19, 11:53 am, Ton van Rooijen tons...@xs4all.nl wrote: This is a very nice enhancement indeed. The syntax however is i.m.h.o. somewhat confusing. Why append the option-name with _cookie:? a) to me it looks like an unnecessary complication of the syntax. b) the syntax more or less suggests (because of the closing colon) that you could still provide a value, which is illogical. So why not simply stick to the original syntax of option-name: value or option-name=value in which value can be cookie, true, false or a real value (like e.g. in txtUserName). W.r.t. the discussion about the preference: cookie vs SystemSettings I would like to suggest 2 possible solutions. Either: SystemSettings take preference when viewed over HTTP, whilst when opened from a local file the cookies take preference. This gives maximum control for the author/owner. Or: The SystemSettings enhancement is even further enhanced by being able to have 2 sets of system-settings: one options-set for viewing over HTTP and one for local use from a file. I fully support the earlier suggestions from AlanBCohen and whatever, to make cookies dependent on the filename of the TW-file. So every TW-file gets its own cookies. P.S. This whole contribution is written based on experience with independent TWs; I have no knowledge of or experience with TiddlySpace. Thanks to all involved for again having a great TW release. On 18 nov, 14:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
Hi! I was just checking out the beta and I noticed that dates seem to be all out of whack. For example, http://tiddlywiki.com/beta/#PersistentOptions shows date modified 20 December 2010 and http://tiddlywiki.com/beta/#HelloThere shows date modified 15 December 2008 (possible, but unlikely, considering the content). w On Nov 19, 12:53 pm, Ton van Rooijen tons...@xs4all.nl wrote: This is a very nice enhancement indeed. The syntax however is i.m.h.o. somewhat confusing. Why append the option-name with _cookie:? a) to me it looks like an unnecessary complication of the syntax. b) the syntax more or less suggests (because of the closing colon) that you could still provide a value, which is illogical. So why not simply stick to the original syntax of option-name: value or option-name=value in which value can be cookie, true, false or a real value (like e.g. in txtUserName). W.r.t. the discussion about the preference: cookie vs SystemSettings I would like to suggest 2 possible solutions. Either: SystemSettings take preference when viewed over HTTP, whilst when opened from a local file the cookies take preference. This gives maximum control for the author/owner. Or: The SystemSettings enhancement is even further enhanced by being able to have 2 sets of system-settings: one options-set for viewing over HTTP and one for local use from a file. I fully support the earlier suggestions from AlanBCohen and whatever, to make cookies dependent on the filename of the TW-file. So every TW-file gets its own cookies. P.S. This whole contribution is written based on experience with independent TWs; I have no knowledge of or experience with TiddlySpace. Thanks to all involved for again having a great TW release. On 18 nov, 14:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
Hi! Also, considering that TW already has a backstage mechanism for setting options (Tweak and/or Options from AdvancedOptionsPlugin (1)), it would be nice if such a mechanism were enabled for SystemSettings. It could be added as a tab to existing options, where you could add a tick to make it cookie dependent and/or set the actual default value. w (1) http://www.TiddlyTools.com/#AdvancedOptionsPlugin On Nov 20, 10:34 am, whatever kbrezov...@gmail.com wrote: Hi! I was just checking out the beta and I noticed that dates seem to be all out of whack. For example,http://tiddlywiki.com/beta/#PersistentOptions shows date modified 20 December 2010 andhttp://tiddlywiki.com/beta/#HelloThere shows date modified 15 December 2008 (possible, but unlikely, considering the content). w On Nov 19, 12:53 pm, Ton van Rooijen tons...@xs4all.nl wrote: This is a very nice enhancement indeed. The syntax however is i.m.h.o. somewhat confusing. Why append the option-name with _cookie:? a) to me it looks like an unnecessary complication of the syntax. b) the syntax more or less suggests (because of the closing colon) that you could still provide a value, which is illogical. So why not simply stick to the original syntax of option-name: value or option-name=value in which value can be cookie, true, false or a real value (like e.g. in txtUserName). W.r.t. the discussion about the preference: cookie vs SystemSettings I would like to suggest 2 possible solutions. Either: SystemSettings take preference when viewed over HTTP, whilst when opened from a local file the cookies take preference. This gives maximum control for the author/owner. Or: The SystemSettings enhancement is even further enhanced by being able to have 2 sets of system-settings: one options-set for viewing over HTTP and one for local use from a file. I fully support the earlier suggestions from AlanBCohen and whatever, to make cookies dependent on the filename of the TW-file. So every TW-file gets its own cookies. P.S. This whole contribution is written based on experience with independent TWs; I have no knowledge of or experience with TiddlySpace. Thanks to all involved for again having a great TW release. On 18 nov, 14:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
Re: [tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
Also, considering that TW already has a backstage mechanism for setting options (Tweak and/or Options from AdvancedOptionsPlugin (1)), it would be nice if such a mechanism were enabled for SystemSettings. It could be added as a tab to existing options, where you could add a tick to make it cookie dependent and/or set the actual default value. We stopped short of adding a user interface for switching options between cookie vs. baked settings to keep things simple at first, but it certainly seems a reasonable idea. I was just checking out the beta and I noticed that dates seem to be all out of whack. For example,http://tiddlywiki.com/beta/#PersistentOptions shows date modified 20 December 2010 andhttp://tiddlywiki.com/beta/#HelloThere shows date modified 15 December 2008 (possible, but unlikely, considering the content). I think that is just because the content was authored in a text editor, and not the full TiddlyWiki environment, and those tiddlers inherited the wrong dates through a slip of cut and paste. Cheers Jeremy w On Nov 19, 12:53 pm, Ton van Rooijen tons...@xs4all.nl wrote: This is a very nice enhancement indeed. The syntax however is i.m.h.o. somewhat confusing. Why append the option-name with _cookie:? a) to me it looks like an unnecessary complication of the syntax. b) the syntax more or less suggests (because of the closing colon) that you could still provide a value, which is illogical. So why not simply stick to the original syntax of option-name: value or option-name=value in which value can be cookie, true, false or a real value (like e.g. in txtUserName). W.r.t. the discussion about the preference: cookie vs SystemSettings I would like to suggest 2 possible solutions. Either: SystemSettings take preference when viewed over HTTP, whilst when opened from a local file the cookies take preference. This gives maximum control for the author/owner. Or: The SystemSettings enhancement is even further enhanced by being able to have 2 sets of system-settings: one options-set for viewing over HTTP and one for local use from a file. I fully support the earlier suggestions from AlanBCohen and whatever, to make cookies dependent on the filename of the TW-file. So every TW-file gets its own cookies. P.S. This whole contribution is written based on experience with independent TWs; I have no knowledge of or experience with TiddlySpace. Thanks to all involved for again having a great TW release. On 18 nov, 14:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en. -- Jeremy Ruston mailto:jer...@osmosoft.com http://www.tiddlywiki.com -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options,
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
Well, as long as it's not a bug. Though, as far as I know we're still in November, not in December. :D w On Nov 20, 3:40 pm, Jeremy Ruston jeremy.rus...@gmail.com wrote: Also, considering that TW already has a backstage mechanism for setting options (Tweak and/or Options from AdvancedOptionsPlugin (1)), it would be nice if such a mechanism were enabled for SystemSettings. It could be added as a tab to existing options, where you could add a tick to make it cookie dependent and/or set the actual default value. We stopped short of adding a user interface for switching options between cookie vs. baked settings to keep things simple at first, but it certainly seems a reasonable idea. I was just checking out the beta and I noticed that dates seem to be all out of whack. For example,http://tiddlywiki.com/beta/#PersistentOptions shows date modified 20 December 2010 andhttp://tiddlywiki.com/beta/#HelloThere shows date modified 15 December 2008 (possible, but unlikely, considering the content). I think that is just because the content was authored in a text editor, and not the full TiddlyWiki environment, and those tiddlers inherited the wrong dates through a slip of cut and paste. Cheers Jeremy w On Nov 19, 12:53 pm, Ton van Rooijen tons...@xs4all.nl wrote: This is a very nice enhancement indeed. The syntax however is i.m.h.o. somewhat confusing. Why append the option-name with _cookie:? a) to me it looks like an unnecessary complication of the syntax. b) the syntax more or less suggests (because of the closing colon) that you could still provide a value, which is illogical. So why not simply stick to the original syntax of option-name: value or option-name=value in which value can be cookie, true, false or a real value (like e.g. in txtUserName). W.r.t. the discussion about the preference: cookie vs SystemSettings I would like to suggest 2 possible solutions. Either: SystemSettings take preference when viewed over HTTP, whilst when opened from a local file the cookies take preference. This gives maximum control for the author/owner. Or: The SystemSettings enhancement is even further enhanced by being able to have 2 sets of system-settings: one options-set for viewing over HTTP and one for local use from a file. I fully support the earlier suggestions from AlanBCohen and whatever, to make cookies dependent on the filename of the TW-file. So every TW-file gets its own cookies. P.S. This whole contribution is written based on experience with independent TWs; I have no knowledge of or experience with TiddlySpace. Thanks to all involved for again having a great TW release. On 18 nov, 14:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/tiddlywiki?hl=en. -- Jeremy Ruston mailto:jer...@osmosoft.comhttp://www.tiddlywiki.com -- You
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
This is a very nice enhancement indeed. The syntax however is i.m.h.o. somewhat confusing. Why append the option-name with _cookie:? a) to me it looks like an unnecessary complication of the syntax. b) the syntax more or less suggests (because of the closing colon) that you could still provide a value, which is illogical. So why not simply stick to the original syntax of option-name: value or option-name=value in which value can be cookie, true, false or a real value (like e.g. in txtUserName). W.r.t. the discussion about the preference: cookie vs SystemSettings I would like to suggest 2 possible solutions. Either: SystemSettings take preference when viewed over HTTP, whilst when opened from a local file the cookies take preference. This gives maximum control for the author/owner. Or: The SystemSettings enhancement is even further enhanced by being able to have 2 sets of system-settings: one options-set for viewing over HTTP and one for local use from a file. I fully support the earlier suggestions from AlanBCohen and whatever, to make cookies dependent on the filename of the TW-file. So every TW-file gets its own cookies. P.S. This whole contribution is written based on experience with independent TWs; I have no knowledge of or experience with TiddlySpace. Thanks to all involved for again having a great TW release. On 18 nov, 14:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
That's great! Which options do you think should be persistent, and which options should be in cookies? This depends on the use of TW. If it's a document for myself, most of things should be backed, including authorName, autoSave, RegExpSearch, probably sliders' states. AutoSave is most important since some browsers (including Opera) don't notify when you close a tw- document without saving. On the other hand, if TW is used as a site (or part of a site) most of them should be cookie-based because they are for users. Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? I think this worths adding one more option. If you do so, when TW is used just by the author, it should be set so that backed ones are precedence. For use as a site, it's just switching that option that's enough to work it properly. Now, let's consider a situation if a tw-document is used by a team of editors. This goes more complicated. I think each author should have some structure describing his or her preferences, like a author_name_SystemSettings tiddler (and perhaphs group_name_SystemSettings). The thing is, TW should somehow recognize the author. This can be done either manually (by some sort of authentication) or automatically (based on cookies, I guess). As for now, I don't see any beatiful solution.. On 18 ноя, 16:06, Martin Budden mjbud...@gmail.com wrote: I'm pleased to announce the TiddlyWiki 2.6.2 beta release. This release consists of a number of minor usability and hackability enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, and one fairly major enhancement. The major enhancement is the addition of persistent options, also known as 'baked cookies'. This is the ability of TiddlyWiki to store some of its options in a tiddler, the SystemSettings tiddler, so that these options are retained even if the user deletes all their cookies, or moves the TiddlyWiki to another computer. The persistent options are more fully described at: http://tiddlywiki.com/beta/#PersistentOptions We are soliciting feedback about Persistent Options as part of this beta release, in particular: 1) Which options do you think should be persistent, and which options should be in cookies? 2) Do you think the persistent options have been explained properly, and do you have any suggestions to improve the explanation? 3) Which should take precedence a persistent option or a cookie? That is should a persistent option overwrite an option previously set in a cookie, or should the cookie value take precedence? This has been the subject of some discussion, and we are by no means sure which is the better option. In the beta the persistent option overwrites the cookie option. Note that for a standalone TiddlyWiki, the impact of the difference in precedence is not that great, but for TiddlySpace the impact is more significant: it means an option set locally by a user in a cookie can be overwritten by another user of the TiddlySpace, if that option is persistent. Martin -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
My suggestion would be that as part of the implementation of persistent (Baked) cookies, consideration be given to including the current file name as part of the cookie ids. I realize not everyone uses multiple open TW files at the same time, but the many uses of cookies in TW currently means that the same cookies are affecting multiple files. I may well want my sidebar hidden in one file but want it open in another. I often use separate TW files to keep separate what would otherwise be one large, slow file, at work, for example, my addressbook, my work diary, my primary collection of links, and my collections of technology notes. Even the username might vary between someone's personal files and a team-based TW file. I'm reasonably sure there would be others with similar needs for distinct cookies between TW files. My suggestion on precedence for identically named cookies would be for the persistent ones to be of lower priority than the session cookies. This would allow the same values at start as were valid at the beginning of the previous session (if the persistent cookies in the tiddlers were not changed and saved during that session) while allowing them to be changed for the session. -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
[tw] Re: Announcement of 2.6.2 beta release of TiddlyWiki
I agree with Alan on using filename as part of the cookie name or perhaps a random ID. Recently, I had four different TWs open, and the username was same in all of them, even though it wasn't supposed to be. As for which should take precedence, I think the cookies. I mean, you set some default persistent options for yourself, which are supposed to be valid most of the time. But perhaps you want to temporarily change one of those options, which you can do with a cookie. Or, to make the discussion void, you could simply add an option for the users to decided for themselves (which would be a persistent option in itself :D). w On Nov 19, 4:10 am, AlanBCohen alanbco...@gmail.com wrote: My suggestion would be that as part of the implementation of persistent (Baked) cookies, consideration be given to including the current file name as part of the cookie ids. I realize not everyone uses multiple open TW files at the same time, but the many uses of cookies in TW currently means that the same cookies are affecting multiple files. I may well want my sidebar hidden in one file but want it open in another. I often use separate TW files to keep separate what would otherwise be one large, slow file, at work, for example, my addressbook, my work diary, my primary collection of links, and my collections of technology notes. Even the username might vary between someone's personal files and a team-based TW file. I'm reasonably sure there would be others with similar needs for distinct cookies between TW files. My suggestion on precedence for identically named cookies would be for the persistent ones to be of lower priority than the session cookies. This would allow the same values at start as were valid at the beginning of the previous session (if the persistent cookies in the tiddlers were not changed and saved during that session) while allowing them to be changed for the session. -- You received this message because you are subscribed to the Google Groups TiddlyWiki group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
