considering HTTP PATCH support for tiddlers

[chris...@gmail.com]

This is a request, not a promise (or threat) that I'm going to change
things. Your input is very much desired.

RFC 5789[1] codifies the HTTP PATCH method as a feature for doing
partial updates to resources. It was originally part of the HTTP 1.1
discussions but didn't make it in because the participants didn't
reach agreement. It's now standards track, but not widely used.

In current TiddlyWeb, resource udpates are _never_ partial. When you
PUT a recipe, bag or tiddler a complete representation of the entity
is sent in the body of the request, replacing the server-side instance.

For the most part this works well:

* It is fairly unambiguous.
* It is nicely aligned with the origial planned content types of tiny
tiddlers.
* It is well integrated with the serialization architecture used in
TiddlyWeb.

PATCH is gaining acceptance and it may now make sense to support it in
some form in TiddlyWeb because:

* It keeps TiddlyWeb aligned with norms.
* Some content (such as binary tiddlers[2]) is not small and doing
partial updates could be more efficient.

A possible scenario is that a User-Agent PUTs a large tiddler, say a
movie, in raw binary form. A followup PATCH sets some tags on that
that tiddler (some header elided):

PATCH /bags/foo/tiddlers/bigtidder
Content-Type: application/json
If-Match: <some etag>

{"tags": ["movie", "****"]}

This changes (patches) the existing "bigtiddler" so it now has tags
"movie" and "****", but the raw binary content (stored as the text
attribute) remains the same.

Using PATCH instead of PUT or POST here is good because there's no
additional distinguishing that needs to be done in the request to know
that the request is a PATCH.

There are several concerns with this that would need to be resolved
before an implementation could be made:

* JSON makes a pretty easy patch content type. Would there need to be
others? Is it in the spirit of TiddlyWeb to only support one?
* In the above example are we setting tags in an absolute sense? Adding
tags? If adding, how do we remove? If adding, is it maybe better to
have tags as a separate (sub-) resource? Are tags special or are all
attributes candidates for sub-resourcing?[3]
* The TiddlyWeb serialization architecture is not set up to handle
partial representations of resources. It would be easier to handle
PATCH outside the serialization stack. This would make things like
doing just JSON easier, but things could get mighty complicated is
other partial representations are to be considered.
* Do bag and recipe entities need partial representations. It might
make sense for policy updates, but the question of add or remove
(as with tags) gets confused again.[3]

It's probably hard for many of the readers to believe this, but
TiddlyWeb strives to limit ambiguity, so my main concern with using
PATCH is that it might introduce some, or even a lot, and it would be
good to avoid that if the benefits are not large.

In a TiddlyWiki context partial updates are probably not a huge win.
Some requests could be completed more quickly, but semantically
TiddlyWiki and the adaptor mechanism work on whole representations,
because they are always there.

As TiddlySpace broadens the opportunities for tiddlers in strange new
worlds, PATCH might be useful.

What do you think?

Thanks.

[1] http://tools.ietf.org/html/rfc5789

[2] https://groups.google.com/d/topic/tiddlyweb/AMOo0GeLwHk/discussion

[3] My thinking on this aspect of things is that a PATCH of a tiddler
would operate on the tiddler as if it is a set of key:value pairs and
with PATCH you can set the value of one or more keys. So if a tiddler
already has tags "foo" and "bar", to add "boom" a patch would look
like this:

{"tags": ["foo", "bar", "boom"]}

Removing foo would look like this:

{"tags": ["bar", "boom"]}

This is not super elegant and expressive, but it is simple to
understand and simple to implement.

With bag and recipe policies, the advantage of a PATCH is fairly
limited if a patch resets the value of an entire key, because the use
case I can most think of is "add user X to policy constraint Y".


--
Chris Dent http://burningchrome.com/
[...]

[Ben Gillies]

> PATCH is gaining acceptance and it may now make sense to support it in
> some form in TiddlyWeb because:

Yep, sounds like a good idea to me.

> * JSON makes a pretty easy patch content type. Would there need to be
> others? Is it in the spirit of TiddlyWeb to only support one?

Given some of the below concerns, it might be nice to support some
sort of diff format as well (though I'm personally unfamiliar with the
different options here).

> * In the above example are we setting tags in an absolute sense? Adding
> tags? If adding, how do we remove? If adding, is it maybe better to
> have tags as a separate (sub-) resource? Are tags special or are all
> attributes candidates for sub-resourcing?[3]
> * The TiddlyWeb serialization architecture is not set up to handle
> partial representations of resources. It would be easier to handle
> PATCH outside the serialization stack. This would make things like
> doing just JSON easier, but things could get mighty complicated is
> other partial representations are to be considered.
> * Do bag and recipe entities need partial representations. It might
> make sense for policy updates, but the question of add or remove
> (as with tags) gets confused again.[3]

It would certainly make updating policies a lot easier (assuming we
sort out the tags issue).

> [3] My thinking on this aspect of things is that a PATCH of a tiddler
> would operate on the tiddler as if it is a set of key:value pairs and
> with PATCH you can set the value of one or more keys. So if a tiddler
> already has tags "foo" and "bar", to add "boom" a patch would look
> like this:
>
> {"tags": ["foo", "bar", "boom"]}
>
> Removing foo would look like this:
>
> {"tags": ["bar", "boom"]}
>
> This is not super elegant and expressive, but it is simple to
> understand and simple to implement.

Agree. For JSON format, this seems like the most sensible and obvious
way to do things.




Ben

[PMario]

Would this PATCH mechanism create a new tiddler revision?
In the case, I load revisions and want to do a diff ..

===

> already has tags "foo" and "bar", to add "boom" a patch would look
> like this:
>
> {"tags": ["foo", "bar", "boom"]}
>
> Removing foo would look like this:
>
> {"tags": ["bar", "boom"]}

As a programmer I'd prefer a mechanism, like {"addTags": ["boom"]},
because it makes "batch" processing much easier. There is no need to
care about the existing tags, that may be different for every tiddler.
Same for {"removeTags": ["boom"]}

or even better
{"ADD": [ {"tags": ["boom", "bang"]},
{"text":"+- diff type text "},
{"fields":????}
]}
where ADD and the "diff type text" isn't nice, since a diff does add
and remove ...

-m

[FND]

----- Original Message -----
From: chris...@gmail.com
Date: 2012-05-14 20:03
> PATCH is gaining acceptance and it may now make sense to support it in
> some form in TiddlyWeb

\o/

> * JSON makes a pretty easy patch content type. Would there need to be
> others? Is it in the spirit of TiddlyWeb to only support one?

Realistically, I doubt anyone's ever gonna use anything other than JSON
for this - so it might be YAGNI.

However, just for kicks, it might be interesting to ponder or implement
support for the text serialization as well - this might then look like a
diff, i.e. `^[+-]<field>: `:

+type: text/html
-tags: lipsum
+tags: foo bar

So, given what you said about the serialization architecture, this might
complicate things... But I don't like the idea of hard-coding JSON as
the only supported format.

> * In the above example are we setting tags in an absolute sense? Adding
> tags? If adding, how do we remove?

I'm inclined to prefer absolute values - i.e. only allow overwriting
existing fields rather than attempting to support automatic merging on
the server-side - as this is far less prone to ambiguity.

While Mario makes a good point why relative operations might be useful,
I'm not sure about the exact use case. It seems to me that a client
sending a PATCH request should already have access to the respective
tiddler (if only for the ETag), so it should not be hard for that client
to determine the exact/absolute field value. Of course in the TiddlyWeb
universe and philosophy, the client is also supposed to know best what
it really wants.

If we decided to support relative modifications for list attributes,
perhaps a simple +/- prefix might indicate the desired operation (e.g.
`+tags: foo` would append "foo" to the existing list of tags).

> If adding, is it maybe better to have tags as a separate
> (sub-)resource? Are tags special

While somehwat related, I'd rather not conflate that question with the
issue at hand.

> * Do bag and recipe entities need partial representations. It might
> make sense for policy updates, but the question of add or remove
> (as with tags) gets confused again.[3]

I'm not sure whether what I said above about absolute vs. relative
updates for tiddler attributes also applies to bags and recipes - but
those are tiny entities anyway?


-- F.

[chris...@gmail.com]

On Tue, 15 May 2012, FND wrote:

> Realistically, I doubt anyone's ever gonna use anything other than JSON
> for this - so it might be YAGNI.

That's kind of what I think too. It is certainly the easiest format to
deal with. In any case there are really only three formats that you
can currently PUT in:

* JSON
* text
* everything else (binary and not-quite-binary tiddlers)

Suggesting text inevitably leads to people suggesting diff-like
formats as you've done, which is neither concise nor stateless (what
happens, for example, if you send a diff with the right Etag on
If-Match, but the wrong '-' bits?). It seems much too icky (I'll say
a bit more about this in response to Ben).

If JSON becomes the only format for which PATCH is accepted then it
becomes quite easy to package as either a plugin or a self-enclosed
module. This would be useful since the handling would not fit in with
the SerializationInterface.

> While Mario makes a good point why relative operations might be useful,
> I'm not sure about the exact use case. It seems to me that a client
> sending a PATCH request should already have access to the respective
> tiddler (if only for the ETag), so it should not be hard for that client
> to determine the exact/absolute field value. Of course in the TiddlyWeb
> universe and philosophy, the client is also supposed to know best what
> it really wants.

Relative operations are not something I want to encourage as I'll
explain in my response to Mario.

>> If adding, is it maybe better to have tags as a separate
>> (sub-)resource? Are tags special
>
> While somehwat related, I'd rather not conflate that question with the
> issue at hand.

I only bring it up because it is an either or thing. If tags are a sub
resource, then they should not be PATCH-able. If they are PATCH-able,
they should not be a sub resource.

>> * Do bag and recipe entities need partial representations. It might
>> make sense for policy updates, but the question of add or remove
>> (as with tags) gets confused again.[3]
>
> I'm not sure whether what I said above about absolute vs. relative
> updates for tiddler attributes also applies to bags and recipes - but
> those are tiny entities anyway?

I'm thinking of policies which have constraint lists that are _very_
long, potentially thousands of users. That's a particular case where
being able to say "add FND" and "remove cdent" from constraint X might
be useful.

_However_: We've yet to see really long constaints in the wild, so
YAGNI.

[chris...@gmail.com]

On Mon, 14 May 2012, PMario wrote:

> Would this PATCH mechanism create a new tiddler revision?

Yes.

> In the case, I load revisions and want to do a diff ..

Diffing has been availalbe since the very early versions of
tiddlywebwiki, so since before tiddlyspace existed:

http://cdent.tiddlyspace.com/diff?rev1=bags/cdent_public/HelloThere/24982;rev2=bags/cdent_public/HelloThere/24983;format=horizontal

But perhaps I'm misunderstanding your statement and you're suggesting
that providing a diff as the request body when doing a PATCH?

> As a programmer I'd prefer a mechanism, like {"addTags": ["boom"]},
> because it makes "batch" processing much easier. There is no need to
> care about the existing tags, that may be different for every tiddler.
> Same for {"removeTags": ["boom"]}

There's a very signficant reason for not doing this.

The TiddlyWeb HTTP API strives to be RESTful and thus follows most of
the constraints of the REST architecture[1]. One of the biggest is
that the HTTP method is the main focus of the action of any request.
You GET, PUT, POST, PATCH of DELETE a resource. You PUT or POST a
representation to update a resource. PATCH gets a bit fuzzy because it
works with partial representations to do updates.

To keep it clean and clear it is important to avoid adding methods
within the body of the request. Your ideas of "addTags", "removeTags"
and "ADD" cross over that boundary and introduce action-oriented
semantics in a place where they are not expected.

Mind you, the entire notion of PATCH sort of does that, so it is not
surprising that you were motivated to think that way.

In fact, I'm rather surprised that PATCH has the Roy Fielding stamp of
approval because it is so squishy...


[1] The big one that TiddlyWeb does not follow in any particularly
strict way is HATEOAS. Someday I'll write up why.

[chris...@gmail.com]

On Mon, 14 May 2012, Ben Gillies wrote:

>> * JSON makes a pretty easy patch content type. Would there need to be
>> others? Is it in the spirit of TiddlyWeb to only support one?
>
> Given some of the below concerns, it might be nice to support some
> sort of diff format as well (though I'm personally unfamiliar with the
> different options here).

There's some overlap in meaning of terms like diff and patch. A diff
shows differences between (at least) two known things, often resulting
in something that can be used as a patch.

From what I've read in this thread thus far what people would like is
some way to say remove or add something, but without reference to what
is already there. So that's neither a diff nor a patch really.

The format (in JSON) that seems to satisfy most people's thoughts is a
dictionary with one or more keys. In the following example tags is
used:

{
"+tags": ["tags", "to", "add"],
"-tags": ["tags", "to", "remove"],
"tags": ["absolute", "setting", "of", "tags"]
}

But then what happens with fields (as they are nested)? And what about
fields that begin with '+' or '-'?

And is the above too much like a method within the representation?

Which returns us to just absolute setting only.

I find myself no nearer a conclusion.

>> * Do bag and recipe entities need partial representations. It might
>> make sense for policy updates, but the question of add or remove
>> (as with tags) gets confused again.[3]
>
> It would certainly make updating policies a lot easier (assuming we
> sort out the tags issue).

Policies are somewhat like fields as they are nested too (from the
standpoint of the JSON rep of a bag or recipe).

[FND]

> From what I've read in this thread thus far what people would like is
> some way to say remove or add something, but without reference to what
> is already there. So that's neither a diff nor a patch really.

Well, the reference would be implicit - by virtue of the ETag
referencing the current revision.

> But then what happens with fields (as they are nested)?

Since we don't have arbitrary nesting, that doesn't seem like a big
issue.

> And what about fields that begin with '+' or '-'?

I guess one could take advantage of the fact that field names must not
contain (leading/trailing/any?) spaces, so " +tags" would work.

...

However...

> And is the above too much like a method within the representation?

Yes, things like "+tags" do smell like RPC to me. Pfui.

> Which returns us to just absolute setting only.

I have yet to see a convincing, non-YAGNI argument for why relative
operations are necessary. (It seems they could always be added later, if
the need arises. `_hash`, anyone?)


-- F.

[Ben Gillies]

>> And is the above too much like a method within the representation?
>
> Yes, things like "+tags" do smell like RPC to me. Pfui.
>
>> Which returns us to just absolute setting only.
>
> I have yet to see a convincing, non-YAGNI argument for why relative
> operations are necessary. (It seems they could always be added later, if
> the need arises. `_hash`, anyone?)

Indeed. If relative operations need to happen in the future, I'd
rather see them happen in a format other than JSON. I think adding
JSON (without any +/-) for now sounds fine.

[chris...@gmail.com]

Well the issue is that PATCH itself is a relative operation, at a
slightly different angle of attack from +tags. A partial update, by
definition is "change something, but leave the rest of it as is". So
if there is value in having PATCH at all, then there may be value in
having slight more relative relativity.

We can call YAGNI, of course, but I'm less willing to go quickly to
YAGNI on an HTTP API change than I am on a Python API change or a
change to the fields of tiddler (which are deliberately unbounded). It
would be useful to play out the conversation a bit longer.

Ben: for the sake of discussion can you strawman a format for relative
operations? What would it look like? Why wouldn't it be JSON?

Everyone: What are the use cases for having PATCH at all? I'll list
the ones I can think of below. Please add what you think. Listing them
doesn't mean you think they need to be supported, but rather that you
can think of them as potentially useful:

* Adding "metadata" to a (large) binary tiddler.
* Quickly adding a tag or tags to one or many tiddlers.
* Adding or removing a user from a policy constraint.

Note that of these the only one that is significantly hard in the
current TiddlyWeb is the first one.

[PMario]

On May 15, 1:49 pm, chris.d...@gmail.com wrote:
> I find myself no nearer a conclusion.

Reading your responses I'd say:

PATCH can be used to update a tiddlers meta information.

As: {"tags": ["foo", "bar", "boom"]} adds a tag
and {"tags": ["bar", "boom"]} removes a tag.
or {"fields": "myfield:used for what ever I want"} sets custom fields.

The advantage of the whole thing atm is, that you can update "big
tiddlers" by just sending small amout of data to the server. Which imo
is a win for both sides (server/client) allready.

That's what I see at the moment.
-m

[Ben Gillies]

> Ben: for the sake of discussion can you strawman a format for relative
> operations? What would it look like? Why wouldn't it be JSON?

How about https://gist.github.com/2701977

I based it on http://en.wikipedia.org/wiki/Diff#Unified_format

It wouldn't be JSON as a JSON tiddler already has a defined structure,
and adding extra magic symbols to that structure seems like a bad
idea. On the other hand, just leaving out the parts you want to stay
the same seems to make sense (to me at least).

[FND]

> just leaving out the parts you want to stay the same seems to make
> sense (to me at least)

I'd assume we all agree on this for PATCH operations (provided that by
"parts" you mean fields).

>> Ben: for the sake of discussion can you strawman a format for relative
>> operations? What would it look like? Why wouldn't it be JSON?
>
> How about https://gist.github.com/2701977
> I based it on http://en.wikipedia.org/wiki/Diff#Unified_format

That particular (pseudo-)proposal seems pretty complex. Calculating
ranges would be quite taxing on most clients. In fact, I took it for
granted that relative operations would only apply to non-atomic,
decomposable fields - which effectively means lists/arrays. I don't
think partial updates of strings are desirable? (I'm aware of the
strawman nature of Ben's post, but this seems like a significant
question.)

So based on that strawman, here's another:

@@ tags
+ foo bar [[lorem ipsum]]
- baz

@@ text
lorem ipsum dolor sit amet

@@ existingCustomField
lorem ipsum

@@ oldCustomField

@@ newCustomField
lorem ipsum

This would translate to the following operations:
* tiddler.tags.append("foo")
.append("bar")
.append("lorem ipsum")
* tiddler.tags.remove("baz")
* tiddler.text = "lorem ipsum dolor ist amet"
* tiddler.fields.existingCustomField = "lorem ipsum"
* tiddler.fields.newCustomField = "lorem ipsum"
* tiddler.fields.delete("oldCustomField")

Note that
* I don't like double brackets, but no use fighting what's already
established...
* "\n\n@@<field name>\n\n" seems a bit weird (non-obvious, ambiguous)
for removing (custom) fields, but the only alternative I could think
of was `@@-customField`, which seems too magical/special


-- F.

[chris...@gmail.com]

On Tue, 15 May 2012, FND wrote:

> That particular (pseudo-)proposal seems pretty complex. Calculating
> ranges would be quite taxing on most clients. In fact, I took it for
> granted that relative operations would only apply to non-atomic,
> decomposable fields - which effectively means lists/arrays. I don't
> think partial updates of strings are desirable? (I'm aware of the
> strawman nature of Ben's post, but this seems like a significant
> question.)

Your strawman and Ben's strawman both strike me as putting a huge
burden on the client to know and construct a complex custom format.

It's not clear to me how these are more comprehensible or usable
than the weird strange JSON I described, or the
spent-too-much-time-in-the-WS-world JSON patch format:

http://tools.ietf.org/html/draft-pbryan-json-patch-01

Unless the content required on the client side is simple enough to write
by hand (in a curl), and the code to process it server side is just a
few lines, it's a clear smell.

Or perhaps I'm just biased against formats that look like diff?

[colmjude]

Could the following be useful:
* Quickly altering a recipe and corresponding filters
* Tiddler title changes
* Quickly changing the value of fields, that change often, belonging
to a tiddler. E.g. in recent project where a tiddler represents a
person and each time the person is logged on and in a new place or
moves the geo.lat and geo.long fields are updated, nothing else.

A question I have is would a PATCH request change the modified date of
a tiddler and the modifier if applicable?

C.

[chris...@gmail.com]

On Tue, 15 May 2012, colmjude wrote:

> Could the following be useful:
> * Quickly altering a recipe and corresponding filters
> * Tiddler title changes
> * Quickly changing the value of fields, that change often, belonging
> to a tiddler. E.g. in recent project where a tiddler represents a
> person and each time the person is logged on and in a new place or
> moves the geo.lat and geo.long fields are updated, nothing else.

Each of these depends somewhat on what you mean by quickly. For
anything but quite large entities the impact on speed is going to be
quite minor. It's only when the body of the request for a PUT would be
up over some large number of bytes would a PATCH be a win in terms of
speed. This is because of a combination of TCP overhead, relative
size of http headers to body, and what's doing the measuring.

When altering recipes I'm not sure there is a good way to alter the
recipe list itself that doesn't involve just sending the entire recipe
list (in order to preserve ordering). If that's being done, and the
policy is small, the win is not huge in terms of "quickly". It might
be useful from a comprehension standpoint.

Title changes couldn't be done with a PATCH because the title is part
of what makes up the identifier of the resource so the operation would
need to involve two identifiers, and PATCH works on just one.

The field changes would be faster if the rest of the tiddler is quite
a bit larger. Otherwise, unclear.

> A question I have is would a PATCH request change the modified date of
> a tiddler and the modifier if applicable?

Yes, as the tiddler has changed.

[Ben Gillies]

>> That particular (pseudo-)proposal seems pretty complex. Calculating
>> ranges would be quite taxing on most clients. In fact, I took it for
>> granted that relative operations would only apply to non-atomic,
>> decomposable fields - which effectively means lists/arrays. I don't
>> think partial updates of strings are desirable?

Indeed, I kept everything as close as possible to the original spec as
I could to raise this sort of question. I think it's somewhat
unnecessary yes, but at the same time, it's does make it a lot clearer
as to what's going on (in your example for instance are you removing
oldCustomField, or simply setting its value to empty?)

>> (I'm aware of the strawman nature of Ben's post, but this seems like a significant
>> question.)

That's the whole point of a strawman surely (raising questions).

> Your strawman and Ben's strawman both strike me as putting a huge
> burden on the client to know and construct a complex custom format.

The syntax is rather ugly, yes. Indeed, ranges in particular seem to
be only relevant in a very small subset of our perceived use cases (if
at all).

The point was to differentiate it from the standard tiddler JSON
format (which removes a lot of the ambiguity that you highlight in,
for example, field names that start with +). Of course, if JSON is
desired, then it may make sense to limit the magic to a specific
field, for example:

{
text: 'foo bar',
patch: {
'+tags': ['baz'],
'-tags': ['foo']
}
}

would change the text to 'foo bar', add the tag 'baz' and remove the tag 'foo'.

> It's not clear to me how these are more comprehensible or usable
> than the weird strange JSON I described,

They're less ambiguous, albeit also more confusing and harder to
create. They're also less likely to confuse new users (at least, after
they get over the initial syntax hurdle) who may be unfamiliar with
the difference between PATCH and PUT (and when to use one or the
other).


Of course, I'm still unsure whether a '+tags'/diff style format is
required over simply recreating the whole tag list plus/minus any tags
that you want.

Field deletion would presumably be handled with:

{
fields: {
'foo': null
}
}

[chris...@gmail.com]

On Tue, 15 May 2012, Ben Gillies wrote:

> Of course, I'm still unsure whether a '+tags'/diff style format is
> required over simply recreating the whole tag list plus/minus any tags
> that you want.

This does seem to be the crux of the biscuit.

The only use case where it might matter is policy constraints that are
very large, but as said elsewhere, we don't really have them (yet).

Does anybody want to fight for incremental changes to individual
attributes? That is a '+something/-something' or similar format?

-=-=-

My waffling comes from the fact that adding PATCH, if it is going to
be added, really ought to be a core change, because an HTTP API is
what TiddlyWeb is. However, thus far there's really only one use case
that seems to have any legs: tagging (or otherwise metadata-izing)
binary tiddlers. That doesn't feel very general. For instance we'd want
it on tiddlyspace.com but I'm not sure where else.

If it's not general, then it may as well be extra-special, and
therefore a plugin.

But for some reason that makes me uncomfortable.

[Ben Gillies]

> The only use case where it might matter is policy constraints that are
> very large, but as said elsewhere, we don't really have them (yet).

I imagine that if policy constraints get too large and unwieldy on
TiddlySpace, then we should start thinking about roles instead, which
might be easier to manage.

> Does anybody want to fight for incremental changes to individual
> attributes? That is a '+something/-something' or similar format?

I'm not particularly bothered about it tbh, though it might be nice we
left it open for the future.

> My waffling comes from the fact that adding PATCH, if it is going to
> be added, really ought to be a core change, because an HTTP API is
> what TiddlyWeb is.

Why? POST is HTTP and you can only POST tiddlers with an extra plugin.

[cdent]

On Tuesday, May 15, 2012 6:26:21 PM UTC+1, cdent wrote:

If it's not general, then it may as well be extra-special, and
therefore a plugin.

I've started working on a plugin that implements PATCH, to see how it feels. 

    https://github.com/cdent/tiddlywebplugins.patch 

My hope is to use it to determine if it's going to work, how much it smells, etc.

So far I have PATCHing of bags working, and I'm still not that sure, as I say in the commit:

    https://github.com/cdent/tiddlywebplugins.patch/commit/8cbb9516257a4db64c993e741e48f95e6c0081b7