feat: Grant access to schema for role (#36)

Fixes #36
Tests are missing since I don't know how to test this, write them and unfortunately my time is limited. I've tested the code for creating and deleting a schema manually in my project successfully.

Yeah, this needs to come with a test. Just look at the handler.test.ts. Not merging code without an actual test that runs that code. And yes, everyone's time is limited.

The tests you did are quite easy to achieve. It is hard to figure out about those grants. I still searching for those queries which can be used for tests...

I found a way to test for those grants on stackoverflow. I added the test and I hope it is sufficient.

I have another idea: should we introduce a concept like schema access or so? That can do what your role property does. Would make it easier to grant access to the schema to more roles, as this just handles only the one role case.
What do you think?
Will have a look at your changes later.

Well yes. But this also applies to databases. I use one RDS serverless instance for all app in my Kubernetes cluster. Within that instance I create a database per application. I only use the public schema, but roles created for and applied to those databases are not allowed to use public. Actually, whatever is done needs to be applies to databases and schemas. One uses multiple databases and another multiple schemas and others multiple databases and multiple schemas.
What I often do is: Keep it simple for the simple case and provide a more flexible way for more complex scenarios. For that simple scenario I would change the role properties of database and schema to roles: Role | Role[]. But if you provide a separate construct for granting and it's that easy for the simple cases then it would be fine as well. Maybe something like this:
interface RoleGrantProps {
  provider: Provider
  role: Role | Role[]
  target: Database | Schema
  grants: 'all' | 'readonly' | string | string[]
}

For the custom grants I don't know enough about what is typically needed. Maybe it is the best the simply allow grant-SQLs here.
Hower, I build CDK stacks for a customer as a draft and would need something released. If you don't want to release the current version in preference of a separate construct, then please let me know so I can replace the new role property by a SQL construct.

Merged, thanks for all the work @stephanpelikan. I agree, we can improve things later.


Issue 128 - Trigger a first build upon fling completion

Applied change suggested by @tnozicka in https://github.com/tnozicka/openshift-templates/blob/master/pipeline-template.yaml#L34
Signed-off-by: Xavier Coulon<EMAIL_ADDRESS>

@ALRubinger @tnozicka, it seems to work here: as soon as I logged into the console, I could see a that a Build was already running.
I did not have time to do further testings (yet), though.

LGMT

6d85abfc3440d379e7135325f7005bbf4b80e57c


Use Time in LocalCoordinateSystem and CoordinateSystemManager

Changes
Use the new Time class in the LocalCoordinateSystem and the CoordinateSystemManager
Related Issues
Closes # (add issue numbers)
Checks

[x] updated CHANGELOG.md
[x] updated tests
[x] updated doc/
[x] update example/tutorial notebooks refactor in an extra PR

Hello @vhirtham! Thanks for opening this PR.

In the file weldx/transformations/local_cs.py:

Line 18:1: F401 'weldx.transformations.types.types_timeindex' imported but unused
Line 24:1: F401 'weldx.transformations.util.build_time_index' imported but unused

Do see the Hitchhiker's guide to code style

I suggest we merge the updated TimeSeries first. Afterwards, I will review the reminders above before merging this PR. I also think that we should update the interfaces (CLASS.time always returns a Time instance) in a follow-up PR. Since most interfaces already support Time as input, the additional work shouldn't be too much.
The plot functions still need to be updated. Should we do it in this PR or a separate one?


Package disabes column sorting after third attempt.

This package disables column sorting after the third try. First i tought it was a laravel Nova issues https://github.com/laravel/nova-issues/issues/2503, but this morning i had an epiphany.
In resources/views/vendor/nova/layout.blade.php i've inserted all the scripts manually (and removed the foreach for tool scripts). When i removed this script, table sorting worked as expected.
//...
<!--<script src="/nova-api/scripts/nova-actions-left"></script>-->
//...

Recently the laravel nova team added the option to remove table sorting on the third click. Perhaps that will help?
Laravel Version: 5.8.37
Nova Version: 2.11.1
PHP Version: 7.2.19
Operating System and Version: Windows 10
Browser type and version: Chrome 79 64-bits
and also
Laravel Version: 7.11.0
Nova Version: 3.6.0
PHP Version: 7.2.19
Database Driver & Version: mysqlm 5.7.24
Operating System and Version: windows 10
Browser type and version: chrome 81 (64 bits)

Fixed in release v0.2.0 for laravel/nova version 2.10.0 and higher

Thanks for your quick support, it is now working like a charme!


[LNT] Add/Remove Hot plug interface on VM1/VM2 does not resume ping traffic on any VM in the same host in linux networking feature after 2nd iteration.

Scenario 1:

Create vhost-user ports using gnmi cli
Hotplug add/del port to the VM multiple times
Create physical ports and TAP ports
Follow remaining LNT procedure.

Ping works in scenario 1 between 2 VMs.
Scenario 2:

Create the ports hotplug port to VM, set pipeline (follow complete LNT procedure)
Check overlay and underlay ping traffic
Delete the hotplugged port
Hotplug add the port
Check the ping again
In scenario 2, ping doesn't work.

Moving ticket to ipdk-io/ovs


QR code error

When i was trying to scan QR code it shows me an error and stops working.
This is the error
"server\node_modules\puppeteer\lib\cjs\puppeteer\common\ExecutionContext.js:221 [1] throw new Error('Evaluation failed: ' + helper_js_1.helper.getExceptionMessage(exceptionDetails)); [1] ^ [1] [1] Error: Evaluation failed: TypeError: Cannot read properties of undefined (reading 'default') [1] at puppeteer_evaluation_script:5:95"
Please resolve it @ahadnawaz585

When i was trying to scan QR code it shows me an error and stops working. This is the error "server\node_modules\puppeteer\lib\cjs\puppeteer\common\ExecutionContext.js:221 [1] throw new Error('Evaluation failed: ' + helper_js_1.helper.getExceptionMessage(exceptionDetails)); [1] ^ [1] [1] Error: Evaluation failed: TypeError: Cannot read properties of undefined (reading 'default') [1] at puppeteer_evaluation_script:5:95" Please resolve it @ahadnawaz585

Hi @Ibraheem0156 ,
I have resolved the issue in the latest commit.
To ensure everything works correctly, please run the following command:
npm install github:pedroslopez/whatsapp-web.js#webpack-exodus

Additionally, I have updated the wwebVersion to 2.2409.0. This version is provided by the WhatsApp Web JS creator from a different branch. Although I'm not certain about its stability or if it includes all features, it works fine for my use case, even without providing a webVersionCache for the bot client.
The bot is functioning correctly now.


Mobile Specific Control?

Is it possible to have screen size control of the toggle?
For example you have a mobile drop down menu you toggle on and off however, when you re-size the browser window it would still be there because the button you used to turn it on/off is also mobile specific?
So once you made the screen a certain size it would toggle off if it was active?

Hi @jezthomp,
Thanks for taking time reporting this issue, and sorry for the delay.
Actually, you can know the state of a trigger by checking its .isToggleActive attribute, so when you reach the screen size, you could dispatch a click event on the trigger if trigger.isToggleActive is true.
Does this helps?
Another thought: you are resizing the browser for development / debugging purposes, but users are in a reading / searching context, so they never (or almost never) do this. So I think your issue is not really one.


Recommended way to force/redirect HTTP to HTTPS?

Checklist

[x] I have read the newlest tutorials and know the correct effect of the functional design.
[x] There is no similar question on existing issues (including closed ones).
[x] I have tried to find the answer on Jekyll Forum and StackOverflow.
[x] My question is based on the latest code of the master branch.

Description
What is the recommended way to force all connections to be redirected to HTTPS? Currently I have a .htaccess file in my root directory which is working for me:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

I saw that http://chirpy.cotes.page/ automatically redirects to HTTPS, but I don't see a .htaccess file in chirpy-demo.
How are you redirecting to HTTPS? What is the recommended way?
Thanks in advance!

To be honest, I didn't configure anything, because the github page has an option to enforce HTTPS for the website. Is your website hosted on github? If this is the case, according to my past experience, github pages will ignore the .htaccesss configuration.

Ah, okay, makes sense. Mine is hosted on ionos, so I will stick with their recommendation which matches other recommendations from Stack Overflow.
Thanks for the speedy response!


RFC / WIP: make "auto-finishing" optional and non-Tracer-specific

Per https://github.com/opentracing/specification/issues/80, there are concerns about the existing ActiveSpan/ActiveSpanSource concepts, what they imply for Tracer owners/maintainers, and what they imply about acceptable idioms for ActiveSpan instrumentation.
This PR is not intended for merge as-is (at the very least it needs more testing and documentation), but is intended to illustrate some relatively small API changes that decouple Tracers from the refcounting business.
There are two problems I'm hoping to address here.

Inasmuch as ActiveSpan/Continuation refcounting might be desirable in some circumstances, there are definitely people who do not like it. Furthermore, they do not want every Tracer to reimplement that logic.
It should be possible to register/activate/makeActive a Span with the ActiveSpanSource without getting into the refcounting stuff ^^^.

Again, this PR is best understood in the context of https://github.com/opentracing/specification/issues/80. Comments welcome, but don't worry about nitpicks/etc as this is not meant to be merged in its current state.

There is some additional information I would like to share here: After several discussions we had internally about our tracer implementation and feedback from developers that are not even concerned with tracing, just good developers who strive for the best abstraction to solve the problem at hand, we came across this question:
Why does a Span has to concern itself with whether it is "active" or not?
This clicked on all of us and we asked ourselves whether such thing as an "ActiveSpan" should exist or not.. our conclusion was simple: there should be just a Span, whether it is InScope/Active/Current, that's a totally different concern that has nothing to do with the Span itself. Then, if there is no such thing as an ActiveSpan then Continuations go away as well and we realize that, at a bare minimum, what is actually needed to properly do in-process context propagation is something that allows you to set/get whatever Span is considered to be Active/Current/InScope. We are trying to come up with an API the is simple, clean and truly flexible and reusable in Kamon and to achieve that, these are the very minimal constructs that really have to be exposed. Making a Span Active/Current/InScope might return an object that wraps the Span, maybe also having a reference to whatever was Active/Current/InScope before so that it can be restored later, but there is no reason for this scoped object to be a Span, just something that wraps a Span.
We had a simple utility to get the current context in Kamon 0.6.x series which we thought might be just too low level and that we could replace it with higher level abstractions like the ones provided by OT, but the reality is that even if we wanted to provide higher level abstractions, the basics have to be exposed. I'm sharing all of this because given the fact that OpenTracing aims to be the common denominator when it comes to tracing I guess it's in the best interest of the community to provide just the minimum APIs to stay flexible and achieve the task, while leaving the door open for more advance features to be built on top of the base APIs.
I would recommend everyone involved in this PR to take a look at what Census (using gRPCs context), Brave and even the old Kamon are doing for in-context propagation. Its just simple, it works, it's proven and many things can be built on top of that.
I know there has been quite an investment in ActiveSpanSource/ActiveSpan/Continuation and I actually liked these abstractions at the beginning but the more we exercise them, the more we realize that there is something that doesn't click and a simpler solution could solve the in-process context propagation challenge. Actually, a simpler solution already solved it for us before and in other tracing systems, there isn't a need to reinvent the wheel here. It is not my intention to ask you to throw away that work, but if we came to the conclusion that is in the best interest of our users to stick to a simpler solution then common sense dictates that we should share our point of view and reasoning on this issue, even if it will just be for the sake of sharing ideas and exposing a different angle to this concern. If there is any interest in discussing a "simpler" solution for in-process context propagation I would be glad to participate in the discussion, otherwise I'll still try to provide as much feedback and insights on this PR as possible.

@ivantopo what you're describing is where OpenTracing API has been prior to 0.30, when it had no opinion about in-process context propagation. It was a major roadblock to instrumentation because it required some 3rd party solution (like jaeger-context) to actually make different frameworks work together.
It is certainly possible to come up with context propagation API that is completely decoupled from tracing, since context propagation is a more general problem (cf. tracing plane by @JonathanMace). But in order to describe the shape of the computation (which is what OT is about), having separate propagation and Span APIs creates a lot of boiler-plate code for instrumentation.
What I like about active span is that it's still an abstraction. Granted, it prescribes certain semantics, but it should be possible to implement ActiveSpanSource on top of any other existing context propagation mechanism if so desired (but I don't know if anyone tried).
I do agree that mental complexity of ActiveSpanSource seems higher than a simple push/pop mechanics of jaeger-context and many other similar implementations.

@ivantopo getting the API right is way more important than worrying about existing instrumentation, so thank you for sharing your perspectives and those of your straw-polled team members.
Re existing solutions: the reality is that a normal Java process today does not have a reliable way to access the current/active/whatever-you-want-to-call-it Span. As such, no current solution "works", as that ^^^ is the ultimate design goal here. This is not an endorsement of the current OT approach, but just a reminder of the actual goal we all share.
For what it's worth, the API originally was more of a "Handle" approach with a span() accessor (much like what you suggested), but someone rightly pointed out that it led to extra typing, hence the subclassing relationship.
As far as API layering is concerned, average users are not supposed to think about Continuations... that abstraction is in place for the purposes of power users and those building things like the OT-Java-compatible https://github.com/opentracing-contrib/java-concurrent/blob/master/README.md ... in that model, the capture() and activate() happen behind the scenes, as they should.
I don't know... you're arguing for the basic building blocks. That is actually what the current API aims to provide... by explicitly modeling the back-and-forth handoff of context/continuation state and an active, write-able Span, higher-level and cognitively simpler abstractions can be built.
If I had to propose a different design that's probably more along the lines of what you're arguing for, we would:

get rid of BaseSpan and ActiveSpan and consolidate around Span proper
create a try()-friendly scoped activation mechanism and an ActiveSpanSource with which to register same
tell people to pass a Span around explicitly where they presently pass a Continuation
give up on the refcounting functionality entirely (at least as something that would work across library boundaries as part of OT proper)
somewhat misc: I might get rid of the "Tracer inherits from ActiveSpanSource" thing and instead create a setter/getter in Tracer for the ActiveSpanSource, thus making them truly pluggable (and testable) across Tracer impls

Is ^^^ more what you're hoping for? If not, please clarify either here or with some other design sketch RFC PR and link to same.
To reiterate, I definitely want to get this right and am happy to put in the time to have 0.30 code migrated accordingly.

@bhs I think my main concern is the fact that the AutoFinisher is used by default and therefore to disable it you need to use the alternate method and provide a null Observer. I think a simple change to make the default "no observer" would make it a lot cleaner.
The try() usage would remain the same - i.e. call Span.finish for manually started spans, and ActiveSpan.deactivate for active spans. The only difference is that the apps would need to be updated to either supply the AutoFinisher when activating the span, or explicitly call the ActiveSpan.finish.
So minimal change to the current APIs, except the app now explicitly determines how active spans should be finished.

I tested it with RxJava instrumentation. No issues :)

Thinking about how important simplicity is in an API like this, I am inclined to agree with @objectiser that no Observer should be present by default. This allows us to clearly document the separate concerns, and to have the documented behavior of abstractions like spans also be their default behavior. I'm not saying that autofinishing couldn't be a better practical default (we have made use of a lot of it), but the bar should be high given how important clarity is, and I wonder if it actually makes the instrumentation more understandable by seeing the explicit addition of an AutoFinisher in the places where it is needed.
But, before we split too many hairs on that I'd love it if we could get some feedback from tracer implementors who have expressed some difficulty with reference counting and context management occurring outside their tracer, I notice they haven't weighed in yet.

@tedsuo I have only one reason to use AutoFinisher by default: it will not break current instrumentations without inserting AutoFinisher in all makeActive/startActive calls.

Regular spans are perfectly fine to be closed explicitly , e.g. with try-catch block - when then start and finish happen in the same method.
So auto-finishing is useful mostly when jumping between execution contexts (e.g. threads) where it's hard to detect when all Continuations have finished. But - isn't such code very rare? IMHO it will be mostly used in instrumentation libraries. And if it's used in application code then most likely it will be in some centralized place dealing with scheduling some tasks or passing messages across threads.
If my understanding is correct then the hassle of adding AutoFinisher will be minimal and the default of noop is much better.

Re existing solutions: the reality is that a normal Java process today does not have a reliable way to access the current/active/whatever-you-want-to-call-it Span. As such, no current solution "works", as that ^^^ is the ultimate design goal here. This is not an endorsement of the current OT approach, but just a reminder of the actual goal we all share.

@bhs saying that no current solution "works" is quite a broad and misleading statement. There are a number of projects succesfully tracing all sort of JVM applications since years ago, before OT and any of the proposed abstractions existed. The reason why there is no reliable way to access the current/active/whatever Span on the JVM doesn't have anything to do with the APIs that surfaced over the years, it has to do with the variety of execution models that are appearing lately with all the reactive, async and non-blocking wave that is covering the JVM. Those challenges are not going to get solved by OT in any way, nor by jaeger-context, tracing plane, gRPC context, my proposal or any other, there is no generic way to solve this problem for everything that runs on the JVM, those challenges can only be solved by developers writing instrumentation based on a deep understanding of how the toolkit they are instrumenting works under the hood so that the decision of when to propagate/activate/deactive can be taken appropriately, the APIs are just a means to that end.
In-process context propagation only requires two things:

A means of getting the currently active Span.
A means of temporarily set the currently active Span, and the key here is the "temporary" nature of this operation.

It doesn't matter if we are talking about instrumenting old boring servlets or reactive applications, these 2 operations are all we need to instrument. The only difference between these two types of applications is when should something set as active and for how long it should remain like that but all in all, the operations are the same: get and temporarily set. That is the very minimum API required, that is what many solutions out there boil down to and, IMHO, that's the bare minimum OT should expose. Moreover, that is the common denominator across many solutions that are working in production right now, including Jaeger, Brave, Census/gRPC and probably many more beyond my knowledge.
This is our current API:
trait Scope extends AutoCloseable {
  def close(): Unit
}

trait ActiveSpanSource {
  def activeSpan(): Span
  def activate(span: Span): Scope
}

Naming aside, this is all we need. With this we instrument everything: Scala, Twitter and Scalaz Futures, Akka, Play Framework and more to come, and this just works (a simpler version of this has been working for 4+ years for thousands of our users). All sorts of challenges arise when working with these tools, the way of thinking is quite different, deferred work is common, having different threads pools and future callbacks hoping across them is the rule, every single interaction between actors is asynchronous and still, those challenges are being solved with this super simple API.
The current approach with reference counting by default works nice in controlled environments, but it is a otherwise fragile approach for numerous reasons already exposed. The new approach in this PR is adding more API surface to opt-out of a feature that probably shouldn't have been in the scope of OT-api in the first place.
With regards to the boilerplate related to having separate APIs, that's debatable. I see how having clean cut responsibilities between abstractions has to be paid with extra typing, but whether one line more here and there is "a lot" of boilerplate or not seems a very subjective, endless discussion and this is probably not the place to have it.
I would like to hear opinions from the rest of the community and if there is enough interest I would be glad to propose an alternative PR exploring the constructs proposed above. Looking forward to comments.

@ivantopo

The reason why there is no reliable way to access the current/active/whatever Span on the JVM (...) has to do with the variety of execution models that are appearing lately with all the reactive, async and non-blocking wave that is covering the JVM. (...) There is no generic way to solve this problem for everything that runs on the JVM, those challenges can only be solved by developers writing instrumentation based on a deep understanding of how the toolkit they are instrumenting works under the hood so that the decision of when to propagate/activate/deactive can be taken appropriately, the APIs are just a means to that end.

Exactly exactly, that is basically what I'm trying to say with my "no current solution works" comment. Of course people have been trying to trace JVM (and every other environment) since the dawn of time. My point is merely that no API for "cross-package propagation" is sufficient in practice for any given "Application Process X" until that API has instrumentation in place for X's dependencies, esp the ones pertaining to control flow.
I really like most of what you said ^^^ and would absolutely welcome an alternative PR, FWIW.
PS: I do want to reemphasize one more critique of the current OT API at master... namely, having an ActiveSpanSource abstraction (which allows for bare TLS, MDC, etc as possible "storage layers") seems somewhat valuable... but unless the ActiveSpanSource can be swapped independent of the Tracer, it's not a meaningfully useful abstraction. So we should probably either just fold the methods into Tracer directly, or we should add some sort of capability like Tracer#setActiveSpanSource (with caveats that active spans prior to that call might be lost in the void... i.e., it's only to be used during initialization code).

The ActiveSpan api has a lot of weight, and even more now. Sometimes the cure is worse than the disease. The rest of this comment is on what @ivantopo proposed:
I completely agree with @ivantopo that abstraction is important. I've done a lot of different instrumentation, and supported many different types of people doing instrumentation. We have all been bitten by prior apis that punt calls to close a scope by design (ex the old thread binder in brave leaked spans and was really hard to debug problems like this)
I've gotten a lot of very good feedback about the new scoping apis which are essentially the same sketch as Ivan, and also the same as how census works.
@jakerobb on https://github.com/openzipkin/brave-opentracing/pull/43 listed some concrete place where he might not know when something finishes before another thing, and that due to it being a dead library having no way to "fix it".  There are some concerns about having a reference to something, and what you prefer to have a reference to.
I would prefer we use real scenarios like these to evaluate not just the chosen design, which ActiveSpan clearly is from insiders, but also evaluate alternative designs or the design of doing nothing. IOTW, we talk a lot and it is often really frustrating because there's nothing behind it. We talk in terms of what body of customers etc does X abstractly and rarely the style of "I am doing X" like jake says for example. The latter is far easier to pin down.
TL;DR; If something is important enough to be a api this wide, it should be important enough to catalog actual things and alternatives tried but not taken, and how end users feel about them (from their own mouths!)

@ivantopo
IIRC one factor that led to ActiveSpan was that in the API that you show (ActiveSpanSource+Scope) there is no place where the currently active span is captured in the current thread for later activation in another one. It's perfectly sufficient to build the parent-child hierarchy and to track the currently "active" span, but for example it is not clear how to copy threadlocals along with the span (there's no point where to create the snapshot of threadlocals). That's why there is .defer() method which creates Continuation.
So, maybe it would be possible to extend the API you showed with defer() like:
trait Scope extends AutoCloseable {
  def close(): Unit
}

trait ActiveSpanSource {
  def activeSpan(): Span
  def activate(span: Span): Scope // activate(Continuation) ?
}

trait Span {
   (...)
   def defer(): Span // Continuation?
}

Now the question is how should defer() behave (in case of thread locals).

one way (above) is to return some other span that is specially prepared for later activation in another thread - i.e. it contains the captured thread locals. It would be sufficient, but might be omitted by mistake. After all the type of Span with captured thread locals and without is the same
make it return some special "activatable" type which can carry thread-local data - and here's how we get Continuation
The rest of the API in master (ActiveSpan) corresponds to the Scope with the main difference being the fact that Scope has just close method while ActiveSpan is an actual Span (BaseSpan to be precise).

So, how I see it, is that you actually propose to drop 3 concepts:

automatic finishing - the main purpose of this PR
the fact that the "activated" type implements Span interface
the way to indicate the "capture" point - the point where thread-local data can be saved to be later restored during "activation".

Did I get it right?

@adriancole yes, please let’s try to compare proposals using real world libraries. RxJava is a nice example because it is very tricky yet can be instrumented with a small surface area: https://github.com/opentracing-contrib/java-rxjava. I would be down to create an issue where we list a set of instrumentations and have a bake off to compare APIs explicitly, if alternate proposals are submitted.
Separately from that, there is absolutely no way the next API is going out without extensive testing as a Release Candidate. That, to me, was the core problem with the last rollout - the only people to really put it through it’s paces had no issue with the chosen API. Others did not really get engaged until it shipped, which is a common OSS problem with some common solutions. So this time we need to make sure all of the tracers currently involved in OpenTracing have met and engaged actively in kicking the tires. I think a test harness based on real instrumentation patterns would be very helpful approach to this… I will write up something more detailed but anyone interested in this please reach out to me.
Review and Recap
Ok, changing gears a bit, I’m going to try to reiterate and summarize the discussion so far, hopefully this adds clarity to reviewers entering the thread or seeking to design alternate proposals. Please +1/thumbsup if you agree with this assessment, or -1/thumbsdown if you think it is off base (and please explain as well!).
There are three pieces to this domain: instrumentation strategies, context management strategies, and tracer client strategies. And there is one large, extra requirement: does the API allow the same instrumentation work for all reasonable tracer implementations, not just one reasonable implementation?
That last bit is important, because it’s possible that this requirement changes the API somewhat from existing APIs - the OpenTracing API has definitely changed in other respects due to this. So I just want to make sure that contributors understand this extra requirement, and to ask whether the various solutions being proposed don’t violate it in some way. Most existing APIs are too narrowly scoped, or make too many assumptions, to be used as-is. Finding an API that is generalized enough to work with many things but not so generalized as to be ineffectual is, IMHO, the core design problem in OT.
Instrumentation Strategies
Wrapping/Observing spans at the point of instrumentation so that the tracer and application do not need to care. This is important because of the  variety of strategies that may be needed across libraries and frameworks, and different libraries within the same application may engage in different strategies simultaneously. An AutoFinish observer is an example of this. The Tracer and application do not know about reference counting, only RxJava/etc cares about this strategy.
Context Management Strategies
Active span management is necessary to allow instrumentation to cross API boundaries. No fundamentally different approach has been proposed to solve that problem. However, there are to options in this case: separate concerns and allow applications to choose context managers independently from tracers, or delegate this responsibility to tracers. Since both configuration options occur at application initialization, the question is simply whether the decoupling in needed.
This layer has been shown to be a helpful decoupling. But, does its presence also serve to dictate too many details around how tracers may be behaving internally, since context management may need to be deeply coupled to the span management strategies that tracers are employing internally.
Tracers Strategies
Tracers have different internal representations, and must translate back and forth between their model and the OT API. This means the API must make as few assumptions as possible, and limit the API to only what is strictly necessary to consume instrumentation in a unambiguous manner.
The API can be limited in two ways: by moving concepts out, to be built on top of it without the tracers knowledge, or by moving concepts in, to be managed entirely by the tracer and not exposed to the user except during initialization.
Next Steps
I’m wondering if we can scope the debate to the issue of context management: in or out.
What I am hearing is that instrumentation strategies have a lot of positive support, because they simplify the core API without limiting choice and future development. Conversely, encapsulating context management as a strategy is more debatable, because while it provides value in some cases, it may also interact poorly with internal tracer models, or may simply be unnecessary to solve the issues that prompted its existence. The proposed alternative is to move context management back to the internals of the tracer, but still expose activate/deactivate semantics.
Conversely, I have not heard (yet) from a Tracer developer saying that they could not work with instrumentation which used an external AutoFinish observer or similar strategy. And honestly, if we can’t do this kind of thing at the call site, or via some other external mechanism, I’m not sure how we can guarantee that all instrumentations will interact with different tracers correctly.
Questions

Do we need to help users who want to use managers like MDC/etc with their tracer of choice, or actually should tracers just be better around supporting common options like MDC? What’s the forcing function for separating context management from the Tracer API?

If we move the activate/deactivate calls down to the tracer, can something like ActiveContextManager be moved back to ot-contrib and then consumed by tracers which would like to offer that abstraction, similar to the lifecycle observer APIs currently being developed? This would not be the same as the context management that was in ot-contrib before 0.30, as there would be better Tracer API support this time around.

Who would like to help create practical tests and examples that illustrate these tradeoffs?

@mabh I think there is a mismatch between your description and the current implementation present in OT-java. The current implementation of capture() does not touch ThreadLocals in any way, just increments the refcount. The only moment when TLs are actually swaped are when activating on another Thread.
There is no need to capture any TL on the source Thread, nor is that happening at the moment, the only thing that really needs to be captured is the Span itself. The current Continuation is just a reference to the ActiveSpan that additionally increments the refCount.. if you rip off the refcount, why have a wrapper of a Span instead of just the Span?.
To address your questions:

Did I get it right?

Yes, automatic finishing goes away.
Yes, there is no need for a "activated" type, just something temporarily set as current.
With this proposal what you "capture" is the Span itself. The Span you get from calling ActiveSpanSource.activeSpan() is all you need to pass to other Threads.

How do you handle passing thread-locals around without capture?

What needs to be passed around is the Span, nothing else. The swapping of TLs happen on activation time, here that would be when a Scope is created and the Scope encapsulates the state that needs to be restored when it is closed.

@tedsuo

The proposed alternative is to move context management back to the internals of the tracer, but still expose activate/deactivate semantics.

Could you please elaborate on how you reached this conclusion? My proposal above is not trying in any way to hide context management, it's just boiling it down to the most basic constructs that ensure separation between in-process context propagation and Span lifecycle.
I'll take your mention of RxJava to develop yet another example, please take a look at this:
  @Override
  public void onComplete() {
    try {
      observer.onComplete();
    } finally {
      continuation.activate().deactivate();
    }
  }

// From: https://github.com/opentracing-contrib/java-rxjava/blob/master/opentracing-rxjava-2/src/main/java/io/opentracing/rxjava2/TracingObserver.java

That continuation.activate().deactivate(); seems to be there because if the captured continuation is not consumed then the ActiveSpan will never finish (@malafeev please correct me if I'm wrong). That is a workaround to the fact that the lifecycle of the Span is affected by the propagation mechanism. This is one of the cases but most certainly not the only one that will surface. As more people start to experience the fragility of ref counting more workarounds will come. This PR is opening the door for workarounds so that later people will patch instrumentations by adding a null Observer, but all in all, those are workarounds to a liability introduced with the whole reference counting thing. Instead of enabling workarounds we should be preventing the problem from happening on the first place.

I’m wondering if we can scope the debate to the issue of context management: in or out.

I think it has never been the purpose of this PR to discuss whether context management is in or out, probably we all agree on that context management of some sort must exist for tracing to be practical. The scope of this PR is "how" to achieve it, challenging the current implementation and proposing alternatives, but all of them with the goal of achieving context management and separate it from the Span lifecycle.
Adding more API surface so that something can be workaround doesn't seem like the right solution to the problem at hand. Thorough research and weighting of existent and proven solutions is the minimum I would expect from a group of people trying to move a truly vendor-neutral standard forward, I'm just doing my part here.
I have expressed my concerns on the fragility of the current approach several times but nobody is addressing those concerns. So,

Can anyone here explain how the ref counting approach available in OT-java isn't fragile?
Can anyone here defend the idea that adding more APIs so that a liability can be worked around is in the best interest of the whole OT community?
Can anyone expose any fragility or limitation of adopting a simplified context management solution?
Can anyone here say why should we ignore the work and research of several teams and go for a "higher level" abstraction that requires workarounds and entangles concerns?

The current implementation of capture() does not touch ThreadLocals in any way

Correct, I believe that in the future tracer implementation should provide a way to register a "listener" which could manage (capture) whatever thread-locals it cares about. Creating wrappers with this functionality is another approach.

How do you handle passing thread-locals around without capture?

What needs to be passed around is the Span, nothing else. The swapping of TLs happen on activation time, here that would be when a Scope is created and the Scope encapsulates the state that needs to be restored when it is closed.

The problem here is when you pass the "span" to another thread and in that another thread create the Scope - it's too late, it can't access the thread locals from the "parent" thread.

either you call activate in the parent thread and it captures thread-locals properly, but then you you can no way to set "currently active span" in the child thread
or you call activate in the child thread - at this point you can no access to the thread-locals in the parent thread.

What you suggest is perfectly sufficient to keep track of active span (when it's kept in a thread-local), but not to propagate other thread-locals along with the span.
My workaround to this:
I wanted slf4j MDC to have current span_id and current user, but couldn't use thread-locals because of above. Also it was before ActiveSpan was introduced. What I did was to create a kind of local-baggage that does not propagate outside of the process but otherwise has similar semantic. I did a terrible hack and replaced MDC implementation to delegate to this local-baggage in the currently active span. And I also added extra logic to my tracer wrapped which copies local-baggage to child spans when they are created.
It kind of works because MDC is designed to be pluggable and it was possible to replace logback's MDC with terrible reflection hacks. But it doesn't seem to be the right way. Also this local-baggage is not a part of OT spec.
I looked at how this is done in brave and I don't really understand how it works, that's the relevant part of the code:
  /**
   * Sets the current span in scope until the returned object is closed. It is a programming
   * error to drop or never close the result. Using try-with-resources is preferred for this reason.
   *
   * @param currentSpan span to place into scope or null to clear the scope
   */

  @Override public Scope newScope(TraceContext currentSpan) {
    final String previousTraceId = MDC.get("traceId");
    final String previousSpanId = MDC.get("spanId");

    if (currentSpan != null) {
      MDC.put("traceId", currentSpan.traceIdString());
      MDC.put("spanId", HexCodec.toLowerHex(currentSpan.spanId()));
    } else {
      MDC.remove("traceId");
      MDC.remove("spanId");
    }

    Scope scope = delegate.newScope(currentSpan);
    class MDCCurrentTraceContextScope implements Scope {
      @Override public void close() {
        scope.close();
        MDC.put("traceId", previousTraceId);
        MDC.put("spanId", previousSpanId);
      }
    }
    return new MDCCurrentTraceContextScope();
  }
}

It does MDC.get and MDC.put in the same thread so it does not support carrying over thread-locals across threads. In case of span-id / trace-id it works as the tracer manages this information, but the the problem with with other thread locals. As far as I understand this approach is not able to carry thread-locals from the "parent" thread from where the span came.

@ivantopo
Thanks for your detailed message. Re your questions at the end, let me take a shot:

I have expressed my concerns on the fragility of the current approach several times but nobody is addressing those concerns.

I'm baffled... literally the first line of the PR description reads as follows:

Per opentracing/specification#80, there are concerns about the existing ActiveSpan/ActiveSpanSource concepts, what they imply for Tracer owners/maintainers, and what they imply about acceptable idioms for ActiveSpan instrumentation.

Can anyone here explain how the ref counting approach available in OT-java isn't fragile?

The refcounting approach at master does seem fraught in that it literally requires refcounting in order to use ActiveSpan. Once that refcounting is decoupled from the activation concept (i.e., what this PR accomplishes), it seems far less fragile to me... as a number of people have pointed out, the refcounting approach is not always appropriate but often simplifies and removes fragility from instrumentation where there are forks and joins of control flow. I would also observe that refcounting is a generalization of the basic Scope / try() {} idiom... i.e., if there are no capture()s, the refcounted version does exactly the same thing as a Scope. It's only potentially more complex when there is asynchronous work, which is a case that a simple Scope fails to capture automatically.

Can anyone here defend the idea that adding more APIs so that a liability can be worked around is in the best interest of the whole OT community?

Your question (as phrased) presupposes its conclusion by calling the current API a "liability" despite numerous framework instrumentations that were actually improved by this approach. I acknowledge that it's unpopular in important circles, though, and I am certainly on board with finding something that more people can be happy with. What I would like to see is a core OT API that does not mention or require refcounting, but to still support that idiom via an (optional) util package, built entirely on top of the core OT API.
If we can come up with a smaller API that will allow some of the core requirements to be satisfied (like the ones @mabn pointed out... especially having a way to capture thread-local state at the appropriate time), I will be as relieved and happy as you, @ivantopo. And as this PR demonstrates, the refcounting per se can be taken out of the core OT API.

Can anyone here expose any fragility or limitation of adopting a simplified context management solution?

@mabn alluded to one important limitation (of not-having capture() or similar). Since the definition of "simplified context management solution" is left to my imagination, it seems weird for me to poke holes in one. Especially since I would actually prefer a simpler approach and would much rather be in a collaboration with you and others to find one (rather than fielding frankly unfriendly questions like these!).

Can anyone here say why should we ignore the work and research of several teams and go for a "higher level" abstraction that requires workarounds and entangles concerns?

This question also presupposes its conclusions so it's difficult to answer in good faith, but I will try. FWIW, "prior art" was not ignored, though it was found to be problematic in certain areas (e.g., the aforementioned capture and propagation of thread-local state, but also handling more complex fork/join scenarios).

Getting back to a more productive voice, how can we work together to find a simpler API that satisfies the requirements here? As I understand them:

(Obviously,) support a direct call path from a Tracer instance to an active Span instance (somehow)
(Obviously,) don't make active Span context management implementation-specific
Never require the refcounting from a caller or implementor standpoint

... but hopefully (at least for myself and others who see its value) allow for an auto-finishing Span approach without coupling a caller to a specific implementation

Make sure that impls have an opportunity to capture TLS state from the thread that creates an async callback, and also make sure that impls have the opportunity to restore it to TLS in a distinct thread when that async callback is invoked
Minimize API surface area to accomplish ^^^

@ivantopo I meant what I said earlier about wanting to see an alternative (and hopefully smaller) API. I agree that adding an Observer to what's there now – even with the removal of the refcounting – feels odd. There were also things like @pavolloffay's #117 during the #111/#115 days... might be wise to give them another look.

hey @bhs, I apologize for such a generalized statement. I do recognize the effort you are making here and last thing I would like to do is undermine it. I wanted to hear more opinions on those topics, not just yours and @adriancole's. Thank's @mabn for exposing your point!
Now, getting back to productivity. I think the best way to start is to narrow down the goals. Form your list:

(Obviously,) support a direct call path from a Tracer instance to an active Span instance (somehow)
(Obviously,) don't make active Span context management implementation-specific
Never require the refcounting from a caller or implementor standpoint

Awesome, :+1:

... but hopefully (at least for myself and others who see its value) allow for an auto-finishing Span approach without coupling a caller to a specific implementation

This is a tricky one. The problem I see with this is that if there is a optional but official (OT-endorsed or even part of OT) way of enabling ref counting and those mechanisms are used in any publicly available instrumentation (which is very likely to happen in OT-contrib) then those instrumentations will only work nicely with those vendors that support reference counting. Currently, that means that instrumentation might not be reliable when used with tracers that explicitly decided not to support such behavior, like Brave, Sky Walking, Instana, Kamon and maybe others but work as expected if using Jaeger, Lightstep or some others that do decide to support it. That segmentation plays against vendor neutrality and we shouldn't let things go in that direction. I thought that this decision could be left to tracers as a optional behavior but then realized how the long term result works against the community. Whatever is decided (yes/no ref counting) has to be consistent across all OT-compliant tracers, partial (and thus, unreliable) support is not much better than no support.
What do you guys think about the above?

Make sure that impls have an opportunity to capture TLS state from the thread that creates an async callback, and also make sure that impls have the opportunity to restore it to TLS in a distinct thread when that async callback is invoked

I have mixed thoughts regarding this one. The whole purpose of baggage is to keep context that is attached to the Trace rather than to any platform-specific construct (like Threads on the JVM). I would argue that OT already provides a way to propagate domain-specific data and that users should use that abstraction rather than enabling alternative approaches. Talking about @mabn's points, the concern of not propagating certain keys to remote entities could be solved by customizing a Tracer's inject behavior without changes to the API... the concern of logging the SpanID requires tracer-specific knowledge and for now remains out of OT's scope (although, adding the TraceID in the log patterns is a quite common need, we might discuss a generalized way of getting that out of tracers but that's topic for another thread).
I also would like to hear what others think about this.

Minimize API surface area to accomplish ^^^

Awesome, :+1:
I would like add one more goal: Ensure that context propagation is not entangled with Span lifecycle management. WDYT?
Let's align on the goals, then moving forward with a proposal will be simpler.

@ivantopo sorry both for the slight delay and the brevity here – juggling a lot of things right now!
You wrote:

[...] The problem I see with [the refcounting] is that if there is a optional but official (OT-endorsed or even part of OT) way of enabling ref counting and those mechanisms are used in any publicly available instrumentation (which is very likely to happen in OT-contrib) then those instrumentations will only work nicely with those vendors that support reference counting. [...]

Very important to note that the PR under review moves the refcounting out of the vendor impls... so that concern would go away, I think? My hope is that the refcounting is possible but can be implemented 100% outside of the OT core API artifact (and also 100% outside of the Tracer impl). I.e., I'd like it to be possible but never required, esp for instrumentation code. (At master right now  it is of course required, which I agree is a problem)
You also wrote:

[...] The whole purpose of baggage is to keep context that is attached to the Trace rather than to any platform-specific construct (like Threads on the JVM). I would argue that OT already provides a way to propagate domain-specific data and that users should use that abstraction rather than enabling alternative approaches. Talking about @mabn's points, the concern of not propagating certain keys to remote entities could be solved by customizing a Tracer's inject behavior without changes to the API. [...]

To do async work, the following things happen, and in this order:

Literally allocate (not run, allocate) the callback and submit it to some executor queue
Possibly in a different thread where the executor lives, dequeue the callback, then ...
Run the callback and cleanup.

I would sleep better if the tracing API had a special affordance for step 1 above (capture() in OT at master, of course). It's useful for the sort of thing that @mabn has already brought up, but it also allows the code that's concerned with context management/propagation to be decoupled from the code that deals with the Span lifecycle (and adding tags/logs/blah). This is something I'd expect you to want, @ivantopo, since you are adamant (and I share this goal, btw) that a revised API tries to separate the concerns of context propagation and lifecycle. Does that make sense?

This conversation has gotten a bit over my head, but @adriancole asked me to chime in.
I did the work in https://github.com/openzipkin/brave-opentracing/pull/43 to update the brave-opentracing bridge to work with OT-API 0.30. It was fairly straightforward at first; I introduced a dependency on opentracing-util and wired in ThreadLocalActiveSpanSource to handle my reference counting. This worked fine for my use (my company has a suite of ~40 Java services, all instrumented with pure OT-API, backed by Brave+Zipkin).
The initial feedback I got from that was that Brave already has its own context tracking mechanism, and that I should use that rather than run my own in parallel. There was also resistance to introducing a dependency on opentracing-util.
So, I copied TLASS and adapted for my needs. I came up with this: https://github.com/jakerobb/brave-opentracing/blob/a7854242af256035800a31fc692571be7e5df9f2/src/main/java/brave/opentracing/BraveActiveSpanSource.java
Note that BraveActiveSpanSource keeps a Map from SpanId to BraveActiveSpan, which among other things keeps a reference to Brave's SpanInScope, which Brave returns when you start a span, but doesn't expose at any other time. The SpanInScope is necessary in order to remove a span from current context, so I hold on to it in the map, and when I'm later told to close a span (and the refcount reaches zero), I pull it out of the map, close it, and purge from the map.
What I have works, and we have it in production using an internal build of brave-ot. That said, keeping the map around exposes me to race conditions and memory leaks in a scenario where instrumentation is done improperly.
I'd really like it if whatever mechanism OT-API eventually provides for context tracking (assuming that feature is retained) had some acknowledgement that there's a backing engine that needs to be kept in the loop, and that the backing engine probably has its own API which some instrumentations might use for which OT needs to be kept in the loop, and provided explicit hooks to enable that coordination.

I feel it's time to give my opinion as the author of the java-spanmanager contrib library. I'm sorry if my comment has too much focus on java, probably due to my limited exposure to other OT variants.
The discussion in this PR seems about making functionality optional that isn't wanted by all. It does so by adding on an AutoFinisher that may become default behaviour. There were very similar ideas (and discussions) with the initial spanmanager PR. The decision taken there was to not blur an already-complex topic by optional constructs, but rather add them separately as needed. In hindsight I'm glad we chose that route and am thankful for all the review effort spent by many (of which @adriancole and @yurishkuro were crucial).
Looking at it from that perspective, auto-finishing is simply a different problem than managing an active span.
Maybe we should revisit the core concepts and create separate API's for them that can be combined but each addressing their own concern?
i.e. ActiveSpanSource becomes only about managing a Span and returning some Continuation that can be closed again.
After all, that is all we need to be able to provide for instance thread pool implementations to automatically activate and deactivate spans in started threads.
For those that wish auto-finishing or have new spans automatically become child of active spans, we could add separate Tracer decorators. Although possible with the current OT-api it involves a lot of cumbersome wrapping of tracers, spanbuilders and spans.
I think adding lifecycle callbacks to the OT-api may make such decorators easier to add on while keeping the ActiveSpanSource a single-concept thing (albeit a rather complex concept).
About the ActiveSpanSource; In my opinion there can be implementations that are bound to explicit contexts or Thread-local variants as well as implementations that keep track of a single active span or maintain a stack of spans. All these decisions should be left up to the implementation. It's possible commonly used implementations find their way into the 'util' realm from the contrib repos (after they're vetted, bug-free and proven commonly used).
Feel free to disagree or try to convince me otherwise but this is my current opinion :wink: ..

I actually like the API with Scope mentioned by @ivantopo and it can be easily adapted to something similar to what exists in master and in this PR:
interface ActiveSpanSource {
    // no changes
    ActiveSpan makeActive(Span span);
}

interface Tracer extends ActiveSpanSource{
    // no changes
    SpanBuilder buildSpan(String operationName);
}

interface Span extends AutoCloseable {
    Span setTag(String key, String value);

    // Creates "an inactive ActiveSpan" which can be "activated" and turned into regular ActiveSpan. It
    // has only a single purpose - to carry some contextual information to another thread. Using
    // "capture" is not mandatory
    Continuation capture();

    /**
     * By default deactivates the span (if it was active) and finishes the span. The behaviour
     * is defined by the lifecycle used to create the span and another lifecycle can be provided
     * at span creation.
     */
    @Override
    void close();

    // yes! it's back!
    void finish();
}

interface SpanBuilder {
    // starts span and makes it active in the current thread
    Span startActive();

    // allows to alter span's lifecycle management - e.g. how Span.close() behaves
    Span startActive(SpanLifecycle lifecycle);

    // no changes, starts inactive span
    Span startManual();
    SpanBuilder childOf(Span span);
}

// represents the scope of span activity. provides access to the span that is active in this scope
// via span(). closed ActiveSpan is no longer valid - it's an error to call span() on it
interface ActiveSpan extends Closeable {
    // It no longer has Span methods! Instead - span get be obtained with span()
    Span span();

    /**
     * By default deactivates current ActiveSpan (but does not finish the span!). The behaviour is
     * defined by the lifecycle used to create the span and another lifecycle can be provided at
     * span creation.
     */
    @Override
    void close();
}

interface Continuation {
    ActiveSpan activate();
}

// interface allowing to slightly alter how span lifecycle behaves
interface SpanLifecycle {
    void onClose(Span span);
}

Some more details: https://gist.github.com/mabn/9246ebb03aa1534b33b98bd728158b11
The main changes:

BaseSpan is no more, there is only Span with all the regular methods. ActiveSpan no longer has Span interface and is just a wrapper. It could be called Scope as well.
Span also got finish() back.

Span.close() now deactivates and finishes the span. One can achieve different behaviour by providing specific SpanLifecycle at span creation - e.g. auto finishing.

Continuation remains - as I pointed out without capture() good support for thread-locals is impossible. But it doesn't mean that it must be supported by the API. Actually, it could be added in the future without breaking backward-compatibility if there's a need for it...  I don't recall anyone explicitly stating that they encountered a case where they needed capture() and the deficiencies around MDC support have workarounds. Maybe the API could survive without it...

btw - i'm referring to threads, but it should be valid for any kind of execution context supported by activeSpanSource

@mabn I have been playing around with API variations, too. I like a lot of things about your proposal. A few thoughts:

one of the motivators for capture() is MDC-capturing; another is that a refcount-based lifecycle needs to increment the reference count at capture() time, not at activate() time. IMO the MDC use case is not strong enough to justify the added API complexity, and I think (?) it's possible to handle the refcounting entirely external to OpenTracing and without an Observer/Lifecycle mechanism... I'm experimenting with that now. So my current feeling is that capture() can be removed from the core OpenTracing API (even if something similar crops up in contrib or another place that's out of harm's way).
startActive() ought to return an ActiveSpan
SpanLifecycle feels like it should either be a larger API or feels like it shouldn't exist at all... can it instead by accomplished via wrappers?
I'm not thrilled about Tracer inheriting from ActiveSpanSource... unless there's something like Tracer.setActiveSpanSource, there's really no "marketplace" for ActiveSpanSources or guarantee of decomposition there

Thoughts?

I have a sketch of a different approach here: https://github.com/bhs/opentracing-java/pull/5/files
Plot summary sans comments for brevity:
public interface Tracer {
    ScopeManager scopeManager();
    void setScopeManager(ScopeManager scopeManager);

    ... existing stuff ...
}

public interface ScopeManager {
    Scope activate(Span span);
    Scope active();
}

public interface Scope extends Closeable {
    void close();
    Span span();
}

More complete thoughts can be found at https://github.com/bhs/opentracing-java/pull/5/files.

@bhs Am I right that this latest sketch boils down to basically identical as a renamed SpanManager minus the deprecated method?

@sjoerdtalsma

Am I right that this latest sketch boils down to basically identical as a renamed SpanManager minus the deprecated method?

Very similar, yes, I should have mentioned that. Only real divergences are the lack of a clear() method, and then of course the fact that Tracer directly integrates with the new API... On that note, I'm not satisfied myself with the fluency (or lack thereof) of startActive with a finish()-on-close-scope helper.

@bhs I agree with your comments. When it comes to your PR return type of startActive might not be the best. What I mean by that is that it forces the use of Scope in the most common case:
try (Scope scope = tracer.buildSpan("...").startActive()) {
    scope.span().setTag(...);
    scope.span().log(...);
}

It would be great if startActive returned the actual Span here as in this simple scenario Scope wouldn't be even visible:
try (Span span = tracer.buildSpan("...").startActive()) {
    span.setTag(...);
    span.log(...);
}

But - it forces adding close to Span and makes it possible for Span to be active without Scope which is not good.
Basically I'd want to have the cake and eat it but I don't really see how.

@mabn

It would be great if startActive returned the actual Span here as in this simple scenario Scope wouldn't be even visible [...]
Basically I'd want to have the cake and eat it but I don't really see how.

Yeah, this is basically how ActiveSpan and Span ended up inheriting from BaseSpan at master. Though that has its own problems. /shrug

Hi all. @malafeev and I have started a repo for Java tracing examples: https://github.com/opentracing-contrib/java-examples
We've just started, but the hope is that we can use it to illuminate the many edge cases we are concerned about, and fork it to present API choices we are seriously considering. Personally, I'm having a little trouble making such a weighty decision just on the basis of code snippets. Please contribute examples, and let me know if you think this approach has value.

@tedsuo @malafeev thank you!
I decided to take advantage of the example-repo work to demonstrate the instrumentation differences between my proposal here and what's at master... there were some syntactic things I didn't like, so I added a Scope.Observer interface that makes it (relatively) clean to add finish-on-Scope-close semantics.
You can see this new Observer interface in my WIP Scope change, and you can see the ramifications for the rough example code in this diff.
By the way, @objectiser pointed out something important in the other demonstration PR... IMO it's very difficult to cleanly handle his concern without introducing most of the complexity of what's in master already (defer(), Continuation, etc), and it seems (?) that most people don't have the appetite for them (I do have that appetite, but I don't want to over-bias towards my personal preferences).
Curious to hear what others think.

Hey everybody. Summarized the changes and testing results of Ben's latest approach (https://github.com/bhs/opentracing-java/pull/5/files) here https://gist.github.com/carlosalberto/28ba04ae3201d87f91eff924e7d427da
That will get an overall idea for those who haven't been lately following the discussion, as well as for those interested in any further changes to this design - specially the Continuation concept, and whether it should be included in the main api or not.
And hopefully this will get things rolling again (feedback, for a start) :)

@carlosalberto thank you for the above, a helpful and accurate summary of things!
@objectiser @pavolloffay @mabn @sjoerdtalsma @ivantopo @jakerobb @yurishkuro @malafeev @adriancole:
Current status given the research done so far
Here's how I see things...

There are naming changes/etc which we can and should haggle over, but AFAICT the only major semantic question still on the table is whether a defer()-like method and Continuation-like interface should be a part of the core API.
Along those lines, the only compelling reason to include defer and Continuation would be that we want to allow for some sort of auto-finishing (aka "refcounted") Scope/ActiveSpan concept in the API without casts
So, the major concern in my mind is whether there's a use case out there that justifies the additional API surface area and complexity.

Note that there is not a debate about whether Tracer impls need to implement refcounting... that can def be factored out into a util layer if we decide to include these extra API concepts. The question is strictly whether the user-facing API should have those concepts.
If there are no major revelations...
My default at this point is to chart a path towards removing defer and Continuation and incorporating some syntactic things like those found in @carlosalberto or my WIP branches to make common-case code terse and foolproof.
Moving towards a mergeable PR
I would like to try to follow the spirit of @tedsou's process doc... most importantly, before merging we should verify sanity in plentiful OT-contrib repos as well as the most visible Tracer impls (e.g., Jaeger and Brave).
RFC
Please chime in with dissenting opinions about ^^^.

Thanks @carlosalberto for your additional PR, but I think @bhs statement about removing defer/Continuation for now would be best. Unless there is a compelling usecase for it at this stage, it may be better to move to a 1.0 of the API without it, and then possibly revisit for 2.0?

I'm all cool with leaving Continuation and related stuff out if indeed there's no compelling case (and with the hope that, when/if we add it later to the API, things won't break). I'm waiting for more feedback for people maintaining tracers, so they can give some input. Else, totally fine with wiping out this.

@carlosalberto which other tracers would you like feedback from? (ex obv mine is to please remove the api) If folks aren't speaking up either they aren't watching or ignoring. You might need to contact someone directly. A lot of open source work ends up meaning actively getting an answer from folks as day jobs are distracting and threads like this are time consuming. Ex. simplify and ask "How would you feel if we removed X for possible revisit 2.0" to any advertised OpenTracing tracer and/or as an issue on any Tracer you can find implemented on github (latter is not that many)

To summarize a lot of discussion on this PR, related PRs, Gitter, OTSC calls, etc: the community seems comfortable removing the defer()/Continuation concepts in the core API. I know of several major software orgs who are happy with same, but there are some POC code snippets (e.g., from @carlosalberto and myself) that demonstrate ways to get most of the benefits with some (IMO acceptable) limited loss of generality.
In terms of actual concrete next-steps, I think the basic shape of the ScopeManager POC is a good compromise. There are a few things I would like to address before sending out a real / non-WIP PR against OT-Java:

The Scope.Observer pattern feels a little heavyweight, honestly... the only two things I can really imagine right now are "don't finish() on close()" and "do finish() on close()". Would we be better off with an enum? Or an extensible/varargs list of options on Scope activation?
Regardless of that mechanism, as @malafeev (and I think others?) have pointed out, the default Scope semantics should probably be FINISH_ON_CLOSE
@yurishkuro wondered if Tracer#setScopeManager(...) might be better to add later. I personally like having it, as there's not much point in having a generic ScopeManager interface if an arbitrary ScopeManager implementation can't be paired with an arbitrary Tracer implementation; and the setScopeManager() method is the means to achieving that goal.
People using defer()/Continuation should have a well-defined migration path to the new API. If they're willing to change import paths, the essence of the defer()/Continuation API can be implemented by a bridge that in turn supports the Scope-based API... at the very least, there must be an ultra-clear set of recipes to migrate common defer()/Continuation code to whatever specifically replaces it
And of course lots of "soft stuff"... out-of-date comments, a README to update, migration instructions from the defer()/Continuation world, and so on

I would like to volunteer to write a PR that incorporates the above (along with anything else that people want to add to the mix). That said, my calendar and email collude to prevent me from writing any actual code during the weeks these days (maybe this will change someday; I'd like to say so, but that may be naive!). But I will definitely participate in any reviewing / shepherding if others have cycles to make progress on the above in the meantime.
(cc @opentracing/otsc, @tylerbenson, @tedsuo)

Closing this PR now that 0.31 is underway: https://github.com/opentracing/opentracing-java/issues/189


Service locator and class names fix

Fixed:
WebsocketCLIController -> WebSocketCLIController

Added factory classmap
'WebSockets\Factory\WebSocketCLIControllerFactory' => DIR .'/src/WebSockets/Factory/WebSocketCLIControllerFactory.php',

Fixed PHP Deprecated:  You are retrieving the service locator from within the class WebSockets\Controller\WebSocketCLIController.

use Websockets\Controller\WebsocketCLIController; -> use WebSockets\Controller\WebSocketCLIController

return new WebsocketCLIController($realServiceLocator); -> return new WebSocketCLIController($realServiceLocator);

Check if state is closed/closing should use in_array, not !in_array

Thanks for support!


Missing types for page error events.

Hi, I can't see the type definition of the page errors.
For example:
page, _ := browserContext.NewPage()
page.Once("pageerror", func(err ???) {
	c.Logger().Errorf("an error on the page was detected: %s", err)
})

I also recommend using custom function types e.g
type RequestFailedEventHandler = func(request *Request)

Hi, great suggestion but hard to implement on my side probably. We would need like in TypeScript the option to overload methods or use type maps based on the first argument e.g. which is not available in Go.

Providing types in Go is afaik not possible for such cases except we create wrapper functions for all of the events which we could do. Let me know if I'm wrong. Also added support for pageError in the PR #82.

Providing types in Go is afaik not possible for such cases except we create wrapper functions for all of the events which we could do. Let me know if I'm wrong. Also added support for pageError in the PR #82.

Correct me, if I'm wrong but every playwright driver consumes JSON from stdout. This JSON represents a specific event with a fixed data shape. Based on the message "type" shouldn't it be possible to parse them as go structs? Then we would need to develop against specific cases to reach type safety.
https://github.com/mxschmitt/playwright-go/blob/90056e2984ad0b64d55a1f54c1de2e64c06f5b2e/transport.go#L44
https://github.com/mxschmitt/playwright-go/blob/90056e2984ad0b64d55a1f54c1de2e64c06f5b2e/transport.go#L63

Correct me, if I'm wrong but every playwright driver consumes JSON from stdout. This JSON represents a specific event with a fixed data shape. Based on the message "type" shouldn't it be possible to parse them as go structs? Then we would need to develop against specific cases to reach type safety.
https://github.com/mxschmitt/playwright-go/blob/90056e2984ad0b64d55a1f54c1de2e64c06f5b2e/transport.go#L44
https://github.com/mxschmitt/playwright-go/blob/90056e2984ad0b64d55a1f54c1de2e64c06f5b2e/transport.go#L63

This is essentially what the C# driver does.

https://github.com/microsoft/playwright-sharp/blob/ac2cc6e95e9a81c918366fa38877e3e7b0aa8682/src/PlaywrightSharp/Transport/Channels/PageChannel.cs#L96
https://github.com/microsoft/playwright-sharp/blob/6b4454035620c5fec7f4ff5e8b78775231deea85/src/PlaywrightSharp/Transport/Connection.cs#L325

They serialize the data based on the method name.

This is essentially what the C# driver does.

https://github.com/microsoft/playwright-sharp/blob/ac2cc6e95e9a81c918366fa38877e3e7b0aa8682/src/PlaywrightSharp/Transport/Channels/PageChannel.cs#L96
https://github.com/microsoft/playwright-sharp/blob/6b4454035620c5fec7f4ff5e8b78775231deea85/src/PlaywrightSharp/Transport/Connection.cs#L325

They serialize the data based on the method name.

Yes its communicating over stdin/stdout with JSON and the payload length prefixed. We already parse them as go structs, internally for some purposes, like pageerror it internally gets converted into a playwright.Error type struct, for worker, its a Worker instance, for request/response its such a object, it depends on the kind of event which type it is in the end.
I don't get the original question maybe, this is now possible:
page.Once("pageerror", func(err playwright.Error) {
	c.Logger().Errorf("an error on the page was detected: %v", err)
})

Does this answer your question?

Yes its communicating over stdin/stdout with JSON and the payload length prefixed. We already parse them as go structs, internally for some purposes, like pageerror it internally gets converted into a playwright.Error type struct, for worker, its a Worker instance, for request/response its such a object, it depends on the kind of event which type it is in the end.
I don't get the original question maybe, this is now possible:
page.Once("pageerror", func(err playwright.Error) {
	c.Logger().Errorf("an error on the page was detected: %v", err)
})

Does this answer your question?

This issue was only about page error events. Your example would fix it. :+1:
In general, I think the driver overuse reflection and empty interface. In many cases, we could develop against concrete types.

https://github.com/mxschmitt/playwright-go/blob/5b4ed0ebc859c8c86596e9b0760d6ae3946c136d/helpers.go#L301-L326
https://github.com/mxschmitt/playwright-go/blob/5b4ed0ebc859c8c86596e9b0760d6ae3946c136d/expect_wrapper.go#L7-L23

I like this approach https://mionskowski.pl/generic-event-dispatcher-in-go to handle events from different types.

This issue was only about page error events. Your example would fix it. :+1:
In general, I think the driver overuse reflection and empty interface. In many cases, we could develop against concrete types.

https://github.com/mxschmitt/playwright-go/blob/5b4ed0ebc859c8c86596e9b0760d6ae3946c136d/helpers.go#L301-L326
https://github.com/mxschmitt/playwright-go/blob/5b4ed0ebc859c8c86596e9b0760d6ae3946c136d/expect_wrapper.go#L7-L23

I like this approach https://mionskowski.pl/generic-event-dispatcher-in-go to handle events from different types.

Cool, thanks for confirming. Some events like that or others are missing, try to come up with them over the next week.
Yeah I didn't do much Go for a while and thought its fine to solve it like that. I wanted to keep the API pretty much the same as we have upstream so it corresponds with Python, Java or C#. If you have concrete improvements, I would be happy if you want to collaborate with me on the codebase, waitForEvent/newExpectWrapper is definitely something which is improvable. 👍

Cool, thanks for confirming. Some events like that or others are missing, try to come up with them over the next week.
Yeah I didn't do much Go for a while and thought its fine to solve it like that. I wanted to keep the API pretty much the same as we have upstream so it corresponds with Python, Java or C#. If you have concrete improvements, I would be happy if you want to collaborate with me on the codebase, waitForEvent/newExpectWrapper is definitely something which is improvable. 👍


[Bug Report] $prompt with inputType:'textarea' can't get focus

Element UI version
2.0.4
OS/Browsers version
All
Vue version
2.5.3
Reproduction Link
https://jsfiddle.net/jf6jv80u/
Steps to reproduce
Use $prompt with inputType:'textArea'
What is Expected?
textarea in MessageBox can get focus
What is actually happening?
Devtools show an error: 'Uncaught TypeError: Cannot read property 'focus' of null'. The cause of the problem at https://github.com/ElemeFE/element/blob/dev/packages/message-box/src/main.vue line 276.
setTimeout(() => {
    if (this.$refs.input && this.$refs.input.$el) {
        this.$refs.input.$el.querySelector('input').focus();
     }
}, 500);

And many places in this file such likethis.$refs.input.$el.querySelector('input') didn't think of inputType: 'textarea'

Fixed in https://github.com/ElemeFE/element/pull/8279


Prototype new documentation layout/structure

This will be based on the v1 sitemap in #82 , and will iterate from there.
As as first step, I forked the libp2p docs site. We can use this for rapid prototyping. (I expect the final layout to change, from a visual design perspective, quite a bit.)

MVP Features

[ ] IPFS Cluster Header @meiqimichelle
[ ] Delete Libp2p Branding  @meiqimichelle
[ ] Move current pages to match draft sitemap architecture
[ ] Create placeholders of new content (marked green in sitemap)
[ ] List of orphan content in README

Progress! Back over to you @pkafei for more content work 🎉 .

Sweet. This already looks so much better than before!

Next Steps:

[ ] Cleanup on content @meiqimichelle
[ ] Cleanup on content @pkafei
[ ] Show MVP to Adrian @meiqimichelle
[ ] Show MVP to Hector @pkafei

We now have the Cluster header on our MVP, and also a draft global nav that's based on our sitemap and the lovely setup at consul.io

@pkafei once I started implementing the global nav, it became clear that our direction wasn't quite there yet in our first sitemap. Several of the items will likely move to the global nav (and then, once clicked on, will have their own 'docs-like' view), and what remains needs to be re-organized such that when someone clicks DOCS, they get a useful left nav. ie, you wouldn't want to click DOCS and then have another side nav section called DEVELOPER DOCS -- oops.
I tried to leave notes in the nav, and in the _index.md for each section so you could see where I'm at. If this is clear enough, please feel free to re-arrange the remaining DOCS sections and their children how you think they make sense (which may include bringing some children up to first-level nav).
Ever forward 💃

I had a quick look and I am really liking what I am seeing. A few comments (note some of this may not yet be in the MVP so if that is the case just ignore them):

I would like there to be a homepage (from the sitemap I believe there will be but just confirming)
Having the outline nav on the left as well as the 'prev page'/'next page' arrows seems like overkill
I have a preference against having 'Architecture' as the first item in the outline nav, also to reference the consul.io docs again :) I find the connotation of having internals>architecture so it is clear that to use the software you do not need to understand this content or even know about it really but it is there if you need to dig deeper

Personally, I think Upgrades shouldn't be standalone, but should be an item under Guides

I think I got the gist @meiqimichelle. Spent the day trying to wire the content and top nav portion of the website. The goal was to get the website to a state where if user clicks on the link API in the top nav they will only see documentation pertaining to the API. Here's what I've done so far:
https://github.com/ipfs-cluster/cluster-docs-mvp/tree/alt-nav
I think to get this to work, we need to create a  default directory and add a main template and use the main template logic in the nav section to properly go to the different content sections.
https://gohugo.io/templates/menu-templates/#section-menu-for-lazy-bloggers
https://gohugo.io/content-management/sections/

I've made progress in what we talked about (ie, combining the docs template with a more flexible global nav). I ended up porting the MVP work into a branch in this repo because it made more sense to use our existing (well-structured) website as a base, and then add on the docs theme, rather than starting from the docs theme, which was never built to have a standard home page and global nav.
So! My latest work is in a branch called new-docs-layout in this repo. It looks like this at the moment (there's been some regression in the styles, but that's relatively straightforward to fix once the logic is working):

The next steps, I believe, are:

[ ] to understand how Hugo multiple menus work, and separate what gets displayed in the global nav from what gets displayed in the side nav. @pkafei if you could focus on this during your day tomorrow, that would be A++ :D
[ ] pull the content changes we made in the MVP to this branch

So when you click on the global nav you now only get the items related to that url on the side nav

Realized today that Hugo uses a WHOLE lot of GO. Perusing through the GO documentation really helped me with understanding and implementing some of the logic implemented in Hugo's template tags.
https://gohugo.io/variables/menus/#menu-entry-variables
https://golang.org/doc/
Next steps:

[ ] Port sitemap content into new doc site
[ ] Get rid of parent nav in secondary navigation

Closer! There are still lots of bugs, but I think this is the right path, template-wise.

Here is what works:

the left nav accordion opens and closes the way you'd expect
the menu is accessible! or, at least on its way there. (try tabbing and hitting 'enter' or 'space' to open and close the accordion items)
styles are closer to the rest of site, and little triangle open/close isn't terrible
link underline snazzy thing is working
took advantage of "chapter" layout that came with the docs theme -- these are section landing pages, as seen in the screenshots
latest content structure that we had going on the other MVP has been ported over here
there's a 'homeless content' section under the main docs tab -- some of that info will get split into other pages

Here is what needs to be looked at sooner rather than later -- @pkafei can you try for these tomorrow?

[ ] P0: Another run at content -- actually try to split legacy content into new pages. This will make things easier to review for the rest of the team.
[ ] P2: Need nav in each section to persist -- currently depends on current page scope, needs to depend on top-level section, no matter how far into the page tree you go. @pkafei when you experiment with this one (or any other scripting/nav stuff), can you please make another branch off of mine? I'm not confident I'd be able to get back to where I was if I needed to ;) Thank you!

For later, braindump -- these are less urgent to fix

Tabbed navigation jumps between nodes/sections, instead of going through every item (such as pages)
Nested sections are rendering twice
Need an active class for a "you are here"

Met with @hsanjuan for an initial MVP review, we now have a doc with more content outline -- this one is ordered by importance as per @hsanjuan , and will help the team to the priority of what needs to be written/reviewed. Doc is here. Eventually, once the pages are relatively settled, we should move that content to an issue so we can check off sections/pages as they're reviewed/finished.

Fixed the nested-headings-rendering-twice issue. Turned out it is a known bug in the accessible accordion module I adapted for our template. I implemented the author's suggested workaround for now, as my JavaScript isn't good enough to PR a proper fix to his code.
TADA :tada: -- only one 'components'

I investigated the keyboard nav issue from a few comments up. Turns out, it is a broader issue. None of our keyboard nav is working properly. I've moved that work to #92 for later, and edited the comment above with that link.

Cluster Documentation Layout
Introduction
Overview

[ ] Feature Set
[ ] Introduction

Getting Started

[ ] Introduction (what is ipfs-cluster-service and what is ipfs-cluster-ctl)
[ ] Using and interacting with ipfs-cluster-ctl

How to pin
How to unpin
How to pin with manual allocations
How to add content to cluster
How to check the status of a pin
Difference between pin "allocation" and pin "status"
How to recover a pin in error state
How to sync pin status to the ipfs daemon

[ ] CRDT vs Raft
[ ] Running Raft

Launching the first peer
Bootstrapping additional peers
Removing Peers

[ ] Running with CRDT

Launching (adding) and bootstrapping peers (will be much shorter than Raft), everything can be
explained in the same place
Trying it out: running ipfs-cluster-peers ls (how to check it your Cluster is up and running)

Guides

[ ] Deploying on Docker and Kubernetes
[ ] Config settings and deployment
[ ] Ansible Playbook
[ ] Data Persistence and Recovery
[ ] Open Census Tracking and Metrics
[ ] Configuration setting for Cluster and IPFS (how is this different from production configuration settings under Guides?)

Architecture

[ ] Pubsub
[ ] Bitswap (intro, maybe links to libp2p and ipfs docs)
[ ] DHT
[ ] Gorpc
[ ] Ipfs-lite
[ ] Private networks

Consensus Components

[ ] Raft

Elaborate on Raft
Elaborate on consensus
Explain the trust model
General operation

[ ] CRDT

Elaborate on CRDTs
Trust models ("Follower" mode, Trust model: trusting peers, untrusting)

Components

[ ] Main Component
[ ] Proxy API
[ ] REST API
[ ] IPFS Connector
[ ] Pin Tracker
[ ] Informer
[ ] Locator
[ ] State
[ ] Consensus

Overview of the APIs

[ ] API Intro- Explain both APIs, ctl can do everything the IPFS API can do
[ ] Rest API- Link to API Reference
[ ] IPFS Proxy API- Link to IPFS API reference
[ ] Clients

Go
JavaScript

Security

[ ] RPC Authorization
[ ] Setting Cluster Secret for RPC API
[ ] Setting Cluster Secret for RPC API

How to Secure Your Cluster

[ ] Don't let unknown peers access your cluster
[ ] Secure the REST and Proxy API
[ ] Ports and Security
[ ] Backup and Disaster recovery

Notes: This outline is heavily influenced by this doc, and makes Guides into a first level section in the Documentation nav.

The Latest:

Fixed in this version

[ ] Search box and sidenav don't stick anymore; they scroll along with the rest of the page.
[ ] Sidenav displays the entire sidenav, no matter how deep you are in the docs
[ ] the sidenav accordions default to open so folks can see all their options at once, and get an idea of what's in the docs
[ ] Heading sizes/weight should be a bit more reasonable, with h1 as the largest/boldest, and the others falling in after (will loop back again later to refine)

TO-DO

[ ] The layout is broken at smaller-than-desktop sizes (was working before; removing the sticky sidenav broke them; should be relatively straightforward to fix)
[ ] Add 'active' class to sidenav
[ ] Improve sidenav styling and interactions. See this article Rules for Modern Navigation for a nice checklist/overview of nav UX to review
[ ] Check the animation on the in-page anchor link scroll. May be annoying. (<-- need to find one to test on)
[ ] Remove sub-table-of-contents at the start of the breadcrumbs (maybe move it somewhere else, maybe just remove)
[ ] Change words in breadcrumbs from lower case to title case
[ ] General padding/alignment refinement (for example, the space between the sidenav and the main content should be a bit bigger; the search box and the breadcrumbs aren't aligned; there should be space between the breadcrumbs and the header; etc)
[ ] (more to come as these obvious problems are fixed -- we can decide if others are blocking issues, or if we can ship a v1 after testing with our team and others)

The Latest on the branch new-docs-layout:

Next up on my list:

[ ] Check on nav/content structure - where should /guides/ live, for example?
[ ] The layout is broken at smaller-than-desktop sizes (was working before; removing the sticky sidenav broke them; should be relatively straightforward to fix)

After that:

[ ] Improve News section layout
[ ] See this article Rules for Modern Navigation for a nice checklist/overview of nav UX to review, check for any obvious gotchas. Known todo: enable tab navigation (doesn't seem to be working for any of our links) and skip-to-main hidden link

And now we're here:

My latest work is on a branch called content__mhz-edits. See PR #96 for status.

I can haz hamburger?

v0 new docs layout has been live for a while. Closing. Can open other issues to troubleshoot.


Convert boxel-ui to v2 addon

boxel-ui is now built with rollup: cd packages/boxel-ui/addon && pnpm build
boxel-ui has four modules with external exports:

@cardstack/boxel-ui/components (import { BoxelButton } from '@cardstack/boxel-ui/components';)
@cardstack/boxel-ui/helpers (import { cn } from '@cardstack/boxel-ui/helpers';)
@cardstack/boxel-ui/icons (import { Warning } from '@cardstack/boxel-ui/icons';)
@cardstack/boxel-ui/usage (import { BoxelButtonUsage } from '@cardstack/boxel-ui/usage';)

svgjar is no longer used
Freestyle app now lives in boxel-ui/test-app
imports within the addon must specify extension (.ts or .gts)
imports from outside the addon do not include an extension
boxel-ui/addon's package.json include rebuild:icons and rebuild:usage to code generate icons and exports

I’ll look more thoroughly but early feedback: should packages/boxel-ui/.ember-cli be moved into …/test-app? Then we get port 4210 by default when running it.

I’m still working my way through the files but when I cloned a fresh repository and did this setup:

pnpm install
cd packages/boxel-ui/addon && pnpm rebuild:icons && pnpm rebuild:usage

Then when I ran pnpm start in packages/boxel-ui/test-app I got this:
Module not found: Error: Can't resolve<EMAIL_ADDRESS>in '/Users/b/Documents/Cardstack/Code/b9/packages/boxel-ui/addon'

Did I miss something?
What I was hoping to see with this is whether the icons that exist are listed, as this is a useful feature of SVG Jar. Browsing the icons in the filesystem doesn’t work well when they have CSS variables for colours because they end up transparent.

@backspace wrote:

Did I miss something?

pnpm build in packages/boxel-ui/addon

@backspace wrote:

Did I miss something?

pnpm build in packages/boxel-ui/addon

lol indeed, it runs now, thanks.
re the SVG browser maybe there could be a list of icons in Freestyle?

re the SVG browser maybe there could be a list of icons in Freestyle

This would be easy to add post-merge 👍

Merged! Let's discuss how we can address the DX issues with Ed in retro tomorrow


location file lost: https://github.com/williamfzc/stf-binaries/raw/master/node_modules/minicap-prebuilt/prebuilt/armeabi-v7a/bin/minicap

2020-05-28 14:36:38.326 | INFO     | fastcap:is_device_connected:39 - device S42 online
2020-05-28 14:36:38.595 | INFO     | fastcap:get_abi:62 - device S422012000560 abi is armeabi-v7a
2020-05-28 14:36:38.831 | INFO     | fastcap:get_sdk:68 - device S422012000560 sdk is 29
2020-05-28 14:36:38.987 | INFO     | fastcap:download_target_mnc:74 - target minicap url: https://github.com/williamfzc/stf-binaries/raw/master/node_modules/minicap-prebuilt/prebuilt/armeabi-v7a/bin/minicap
Traceback (most recent call last):
File "C:\Program Files\Python38\lib\site-packages\urllib3\connection.py", line 156, in _new_conn
conn = connection.create_connection(
File "C:\Program Files\Python38\lib\site-packages\urllib3\util\connection.py", line 61, in create_connection
for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
File "C:\Program Files\Python38\lib\socket.py", line 918, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 11004] getaddrinfo failed

https://stackoverflow.com/a/7335972
网络炸了?


backend/local: fallback retryIngest to retryWrite

What problem does this PR solve?
Fallback retry ingest with retry write and ingest due to https://github.com/tikv/tikv/issues/9496
What is changed and how it works?
Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Side effects

Possible performance regression

Related changes

@Little-Wallace @overvenus PTAL

@Little-Wallace @overvenus PTAL

/lgtm

/lgtm

/merge

/merge


Proposal: Archive this repository

This repository has not been under active development for some time. I missed the deprecation notice and used it just this week, I wish I'd known this repo is effectively frozen & looked for an alternative. I have added a harder-to-miss deprecation notice.
Is there any reason not to archive this repository?
This would clearly indicate to users that work on this repo has ended & they can choose to use it or not fully informed of this fact.

Well then . . . without further ado? Would you like to click the archive button? Thanks!

i was kind of waiting for some other people to chime in, maybe @chrisirhc ?

also lol it appears i do not have that control over it any more (member vs collaborator i guess), so i couldn't do it anyway

Seconded, seems like this should be archived

cc @jonathanbaker7 can you help here?

Yes, I can.  Please have someone from the @uber/viz team log a ticket in our internal Jira, and we will get this project marked for archive and transfer to the Uber-Archive organization.

Hi there, is this repo active or not, in fact? If tis repo is archive, I need to consider migrating to another lib.

Unfortunately, this library is no longer under maintenance.  It will be moved to archive shortly.  I suggest you either fork it, find another library, or feel free to take it over if you want to do maintenance.


fetching: export utilities for decompressing and parsing partition fetch responses

Background
In grafana/mimir we are working towards making fetch requests ourselves. The primary reason behind that is that individual requests to the kafka backend are slow, so doing them sequentially per partition becomes the bottleneck in our application. So we want to fetch records in parallel to speed up the consumption.
One difficulty I met when issuing FetchRequests ourselves is that parsing the response is non-trivial. That's why I'm proposing to export these functions for downstream projects to use.
Alternatively, I can also try contributing the concurrent fetching logic. But I believe that is much more nuanced and with more tradeoffs around fetched bytes and latency. So I wasn't sure whether it's a good fit for a general purpose library. I'm open to discuss this further.
What this PR does
Moves (*kgo.cursorOffsetNext).processRespPartition from being a method to being a standalone function - kgo.processRespPartition. There were also little changes necessary to make the interface suitable for public use (like removing the *broker parameter).
Side effects
To minimize the necessary changes and the API surface of the package I opted to use a single global decompressor for all messages. Previously, there would be one decompressor per client and that decompressor would be passed down to (*cursorOffsetNext).processRespPartition. My understanding is that using different pooled readers (lz4, zst, gzip) shouldn't have a negative impact on performance because usage patterns do not affect the behaviour of the reader (for example, a consistent size of decompressed data doesn't make the reader more or less efficient). I have not thoroughly verified or tested this - Let me know if you think that's important.
An alternative to this is to also export the decompressor along with newDecompressor() and the auxiliary types for decompression.
Note to reviewers
I haven't added explicit tests for this because it's not new code and consumer_direct_test.go already tests it. Happy to add tests if you think they're necessary now that this is exported.

Thanks for taking a look.
I also tried to think about alternatives to the options struct: we can create a FetchParser (name TBD ofc) struct that's constructed with a constructor which takes the same parameters as the options fields. Then ProcessRespPartition is a method on that struct instead of just a standalone function.

We ran into this problem as well today looking to convert a custom Fetch from Sarama to Franz which pulled a single record given topic, partition, and offset. I haven't looked at the PR itself as I haven't looked at it but would love to see a way in the API to fully parse the responses into records.


CASMINST-6066: BOS export/import: Linting

Description

Linting (and other minor improvements) of the BOS import/export procedure, ahead of more substantial changes, so that the upcoming PRs can be focused just on the technical changes to the procedures.
Checklist

[X] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[X] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[X] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

/backport release/1.4 release/1.3