>
>
> I guess you fear users may break functionality of their TW when playing w/
> JS, right?
>
No, the concern is with situations where content is brought together from
other sources (as with importing, or TiddlySpace-style inclusion). We need
to be able to display untrusted wikitext. If we allowed unfettered JS
access in those situations then just importing some documentation from
another wiki might have unintended side effects, as well as potentially
being a vector for data theft. Services like (say) Facebook, Twitter,
Google go to a lot of trouble to weed out JS and HTML in posts to prevent
these sort of things.
None of that is a concern for people running a single user TW who never
import untrusted content, but the design for TW5 needs to be able to cope.
Any sandboxing could be optional, but would need to be mandatory on a
shared service like TiddlySpace if it were to be robust.
* You want to insert another JS interpreter written in JS. What is the
> performance impact? (Consider not only a short filtering expression, but
> maybe a use case to generate data to visualize with D3.)
>
See above. The proposal is to use the JS interpreter as a way to implement
a sandbox so that we can run untrusted JS in the course of rendering
untrusted wikitext.
> * What is the complexity impact for maintaining TW as a whole?
>
Conceptually, it's not very complex. There's been a lot of work on JS
parsers and interpreters in JS.
> * What is the size impact? (What is the size of an empty TW? What about
> automatic saving? Will the whole TW be saved if a single tiddler changes as
> in TWC?)
>
I'm not sure if these questions relate to the JS interpreter idea. At the
moment TW5 doesn't minify it's JS code, and there's no particular effort
being made to optimise the size.
When you use the single file edition then, yes, of course the entire file
has to be saved for each tiddler. Not if you run under Node.js, though.
> * What is the freedom impact? What can I do with a completely sandboxed JS
> interpreter? (Personally, I would choose freedom over safety.)
>
The point of the sandbox is to prevent code you don't trust from doing bad
things. There's no reason to saddle code you write yourself with it (or
indeed any other code you trust).
> * Is it possible at all to get a _save_ TW?
>
I'm not sure what you mean?
> * You are considering even more languages? Can this really be handled? In
> the core of TW?
>
No, I'm proposing that we specify a format for future extensions that add
new filtering languages. The only alternative filtering language I'd
consider for the core is JS, but I much prefer JS that is encapsulated in
tiddler modules, rather than JS interleaved with wikitext. Hence the
discussion above.
> Please understand above statements as concerns. I am far from judging
> anything. So perhaps these concerns are unsubstantiated.
>
I should have made the motivation for sandboxing clearer.
Best wishes
Jeremy
>
> regards
> Michael
>
> Am Montag, 16. Dezember 2013 10:14:57 UTC+1 schrieb Jeremy Ruston:
>>
>> Sorry to be late to this discussion.
>>
>> 1. I'm interested in extending (and documenting) the current filter
>> syntax to cover more use cases. During the beta we can tolerate mild
>> backwards incompatibility, but the ship has already sailed over the general
>> format of filters
>>
>> 2. Like Michael, I don't want to see the filter syntax get much more
>> complicated; as it approaches JavaScript levels of complexity it would make
>> more sense to let users access JavaScript directly
>>
>> 3. I'm also interested in completely new filter languages. Like Stephan,
>> I'm interested in Lisp. So, I think it would be useful to define a syntax
>> for specifying the language used in a filter.
>>
>> For 3, we could have an optional type marker at the start of the filter
>> string. For example:
>>
>> <tw>: [tag[Jeremy]tag[oldschool]]
>>
>> Or
>>
>> <lisp>: ((((((lisp code here)))))
>>
>> <js>: return wiki.getTiddlerList("myList");
>>
>> 4. I worry about the safety of JavaScript embedded directly in wikitext.
>> I'm hoping to use something like this to be able to have the option of
>> running JS properly sandboxed:
>>
>> https://neil.fraser.name/news/2013/12/05/
>>
>> Best wishes
>>
>> Jeremy
>>
>>
>>
>> On Sun, Dec 15, 2013 at 8:08 AM, Michael Herrmann <[email protected]>wrote:
>>
>>> Hallo Stephan and all,
>>>
>>> I would like to share some basic considerations regarding user interface
>>> via dedicated wiki language features vs. using JavaScript directly.
>>>
>>> - From my point of view there is a risk to provide TW features via a
>>> new, dedicated syntax that is only slightly shorter and slightly easier
>>> than JavaScript itself. ( as mentioned above )
>>> - When this happens, then we loose in many aspects:
>>> - The code grows.
>>> - Maintainability decreases.
>>> - We have to learn something completely new (compared to some
>>> established technology like JS).
>>> - On the other hand when the
>>> *user-recognizable-complexity-distance*between JS syntax plus context
>>> requirements and a dedicated syntax is high
>>> enough, then this pays off a lot. For sure.
>>> - Keeping a good ratio should never be forgotten.
>>>
>>> But there's more to it:
>>>
>>> - I would think of myself as some kind of intermediate user: I am
>>> far from understanding the inner workings of TW5. But I do not fear to
>>> write a couple of statements in JS.
>>> - In fact, Jeremy can never foresee all the use cases that come to
>>> our minds. So he will never provide mechanisms for everything.
>>> - There will always be people like me, who want to make use of TW in
>>> an unforeseen way.
>>> - From that point of view, I even prefer a well documented and easy
>>> to use JS interface.
>>> - Of course, those intermediate users are a subset of all the users.
>>> - The real power users, like Stephan, Mario and others have no real
>>> problem.
>>> - But there are also the beginners.
>>> - Perhaps the following principle would help us all:
>>> - Whenever things become more complex, let's find an easy and
>>> well documented JS interface.
>>> - Now that we have a clear plugin mechanism, we can add dedicated
>>> syntax plugins for those situations that are too much for total
>>> beginners.
>>> - Then everyone can choose between both. Advanced users can even
>>> exclude those beginner's-helper-plugins.
>>>
>>> As a summary I clearly vote for not excluding JS as interface in all
>>> situations.
>>>
>>> Regarding list/filter/template context: For me, this is an example where
>>> I could imagine a JS interface that should not be too complex compared to
>>> the current syntax.
>>>
>>> best regards
>>> Michael
>>>
>>>
>>>
>>> Am Freitag, 13. Dezember 2013 20:43:30 UTC+1 schrieb Stephan Hradek:
>>>
>>>>
>>>> I think, we don't need a new filter syntax. We need better
>>>>> documentation for the existion one.
>>>>>
>>>>
>>>> We need enhancements for the existing one. Tell me how to filter for
>>>> one of the custom fields I called "is", "sort", "links", "prefix"…
>>>>
>>>>
>>>>
>>>>> Atm it is one page [1] TiddlerFilters.
>>>>>
>>>>
>>>> But here I agree… The documentation needs enhancement.
>>>>
>>>>
>>>>
>>>>> The filter syntax parser may need some adjustments too, to make
>>>>> everything consistent. eg: whitespace for readability should not disable
>>>>> the filter function.
>>>>>
>>>>
>>>> I also agree here.
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "TiddlyWikiDev" 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/tiddlywikidev.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> Jeremy Ruston
>> mailto:[email protected]
>>
>
--
Jeremy Ruston
mailto:[email protected]
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" 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/tiddlywikidev.
For more options, visit https://groups.google.com/groups/opt_out.
