janl commented on PR #5792:
URL: https://github.com/apache/couchdb/pull/5792#issuecomment-3675371535
We also had a discussion in the last dev meeting and I’m posting relevant
bits from the transcript here (some of what Nick is covering he’s already added
above).
re if/then/else naming of terms:
- I mean I had similar thought. I mean I read the whole thing. I was reading
it for the last hour and I didn't get all the way through to the end because
there's an awful lot in there. and the one that stood out for me was if then
else. Just seems very strange. Those aren't the right words, I don't think, for
what it does. I get the intention of what if then else does, but if is run if
the thing that matches matches and then is then done afterwards it was very odd
to me. I don't think that's quite the right terms for that stuff. But that's
detail. (Bob)
- My concern really is that I think we're inventing a new language just in a
fairly obuse manner and maybe that's fine. is there any precedent for it
though? does Mongo itself have this syntax and we're just aping it or… (Bob)
re adoption:
- I mean I realize the barrier of entry for people to write VDUs writing
JavaScript there are people that do like doing that and there are quite a lot
of people we have that don't like doing that. are they going to doing this
better given how poorly they like writing selectors in my experience as so I
mean I don't want to it's a great proposal…but I just wonder if it's the right
way to what are we trying to solve the fact that doing the JavaScript thing is
slow or is it that JavaScript is an unpleasant way to write it I guess it's
both… (Bob)
- The point I was trying to make with all this [references] is that I could
envision a future where we have a lot of example documentation for all these
selectors.
Jan Lehnardt: sorry for the validation selectors that for the lack of a
better term and maybe even have support in Photon to put them together and then
make it easy to construct these design documents so people don't actually have
to go into the intricate details of it all but there's this web standard
subcategory of micro formats whereas it's just like an here's how you do an
email address how you do the HTML markup and you just import this you give it a
bunch of values and then it does the right and that it's a little bit more
machine readable across the web. so my thinking is we'll build a bunch of quote
unquote types for typical stuff that people would want to validate and then
they can just plug that together any way they want. and then it's a little bit
easier than having to learn all the intricate details of all this kind of
stuff. And then there's going to be plenty of examples of people can know… (Jan)
sidebar about just the performance aspect of running JS VDUs:
- I mean, we could be running quickjs in process, could we not? (Bob)
- We could right I mean it's be kind of a bit dangerous like it we'll try to
avoid that for now. (Nick)
- Jan translates this as “technically possible but maybe practically not
feasible for CouchDB’s stability needs”
- Bob recounts lua in haproxy as a viable option, but that’s not somnething
that fits CouchDB
re can this be simplified?
- I'm thinking from the perspective of what if we just did simplify it and
it might not cover 100% but it might cover 80%. let's say even with a simple
selector if you just say I'd like to mash or not and then if it doesn't it
throws a formid like you don't get a choice to do these paths and do but let's
just do the simplest thing could you do that and then we can look at maybe a
whole bunch of examples and we see we need to really do this string ends with
we need to cap together maybe two things or we need to get the type of
something like it's really crucial that when you v you do this video use I want
to know the type is a number here and we don't really have is number so maybe
there's just sort of a smaller set of minimal kind of checks or things but we
can also use them in a regular indexer as well an indexing can say I'd like to
if it's a number I'm doing something else I emit this way if it's not I do that
for… (Nick)
- And we already have So we have this select a language that we kind of
impose and say it's there and I don't want to depart too far from it or add too
much to it and I'd rather keep it as small as possible because already know
selectors use selectors for more things as opposed to selectors plus it has a
bunch of other things just for VD use maybe an extensions or… (Nick)
- contra: I think that's really where I currently am is is there a way that
we're adding lots of extra options and hoping we cover everything. It's
inventing our own language, which is fine if you get it right. It's complexity.
I mean, I'm not quite on Nick's page with a version of this that's just less
complicated. I mean, I think if you're going to do this, you need to cover
everything you can. Otherwise, who's going to use the damn thing? They'll just
have to use JavaScript.
(Bob)
re implementation:
- Of course, you're concerned. I mean, I mean, it's not you [Nick] or I
going to be writing the code. (Bob)
Bob sums up his thoughts:
- where people try to use it, don't understand it. I'll have to learn it and
then I'll have to fix the bugs in it and they'll have to add functions that we
didn't think of. so there's the maintenance aspect that I'm concerned about.
- I don't object to the idea. I don't think it's technically wrong. I can't
think of an alternative, Literally, embedding lure would make me happy, but I
mean wouldn't make anybody else happy. I think you can walk away. You can say
yes, if you can write it in this language is complete. You can write anything
in that. It's just a question of how much you want to write. if someone else is
building it and it's going in and my only concern would be that it's a quality
that it comes in, it's got lots of tests. coverage is there as complete as it
can be that it's well written it's well documented and that it doesn't crash
couch if you use it in stupid ways so from that point of view you fill your
boots with my cloud and
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
