Open Telemetry Uncategorized, 31 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-05-31 meeting

Description

Instrumentation: Messaging

A

Hey good morning.

B

Morning, everyone good morning.

C

Hey ted, I think you're out this week.

B

uh No, I was, I was out uh last week, yeah time flies saturday, yeah.

C

um So you pinned me on uh slack a while ago about the uh attributes my comment around attributes not being unified, so I I found the case and I just dropped the average spec issue. I've just dropped into chat um where the attributes of a trace are flat, even though they're backed by the proto buff, which supports nested um the spec says it doesn't, so I would like to see it expanded, but it's already starting to get pushback saying this is intentional. Sorry.

D

Yeah, I think the um none of the languages today have support for um anything other than primitive data types and array of those, uh but not an object itself.

C

D

I think they need.

C

To and it's part of like logs logs to find it is that they should support it, so it's like- uh and I know for javascript that actually everything's, backed by attribute value, um which I I had a quick look at your prototype there, martin, which looks good, uh but by using attribute value. It's like it's gonna, be flat.

C

It's not gonna, be an object, so I would like to see it expanded so that it's all an object and had nested everywhere, um as I mentioned in the log seed last week, the the concept of asking traces or logs for the events api. I I find that appealing, because that resolves some of the issues we've got about. Do. How do we auto attach the spam? What's because?

C

Well, if you're, adding events to a span, then fine and for ajax requests which are going to be on a span then having you know, additional events on that makes sense, as opposed to sending it in logs also means we can escalate how quickly some of these events can actually get public because spain's, but not vlogs,.

B

um I I do recall there were like there were concerns around people, um just like dumping objects into uh into trace attributes without first defining how they should be serialized.

B

um So I think that's possibly where the the pushback is coming from, but maybe a solution there is, if we're not doing that with logs, is to to figure out what changed between when, like the tracing group made. That decision and like what the logging group is now saying,.

B

Yep- um and I also think it's uh reasonable to point out that the specific use case you're having um in javascript browsers where you don't want to double serialize.

C

We don't unless double serialize, if we can unify everything as much as possible, so you're having to have multiple code handling in different ways. It's just a bunch of stuff yeah.

D

So um I I would like to um propose uh an alternate uh uh method that can solve a bigger problem, uh which is the you know, bigger payload size.

D

um I I I think the concern here is that many of our attribute names are namespaced, so a dot b, dot c a kind and the the prefix is- is often repeated right among attributes, and that is the main concern why you know nev wants on the a just a as the you know, attribute name, and the value is an object where all the b's are listed right. As you know,.

C

Yeah, sorry to catch you upstairs, I I know where you're going in it's okay, so it's not just for the ones we defined it's for the user ones as well, having the concept of knowing short names.

C

You end up with with the extra mapping memory like uh for uh for identity. We we we did this a bit funkily yeah and it's still used today. So we were embedded in in the cookie, is essentially a bunch of key values um and on the server side we generate effectively the the short key mappings so that the javascript that gets generated from that does use short names, but that's only for the no no, instead of names.

D

It's I'm not no, no, no, so so uh bear with me for two minutes. I I um I think we have two uh proposals right. I think uh one that you are suggesting where we uh support an object as an attribute value, and I have a in a feeling that uh it's going to get a pushback because we in our it has to be no tip.

D

You know explaining how the other languages, the the you know, um concerns outside of client side telemetry, how they would use that uh you know uh you know once that object value for an attribute, because we are only proposing uh we're only talking about the problem. We also need to, you know, propose a comprehensive solution.

D

uh Therefore, you know my second uh proposal. I I think it has a lot of flaws. I can think of it myself, but I want to you know, propose it. I mean at least discuss it so that you know maybe ideas can emerge and- and there is a potential for custom attributes as well. uh Now I think all uh what I'm thinking is that.

D

For each attribute, um what if we and and remember that you know we are going to repeat a lot of we're going to have like you know, tens or twenties or even hundreds of events uh are, you know spans in a in a given request right, so uh the attribute names are longish and they are repeated and it is very common in the in the browser world. uh You know to use like a single letter, url parameters, right, url, query parameters.

D

You know they use very obfuscated, that's mostly for security reasons, but it also helps in reducing the size of the data you know sent over the wire. So my my proposal is that we have a dictionary at the top of the initial payload uh initial request when, as you know as before, we send out saying this is my in attribute dictionary and then for each attribute. You define the short name that will be used right and then you use that short single letter.

D

uh uh You know uh single letters in each of the you know attributes, uh and this is more of a transparent layer. uh You know transparent to the you know both side application. That has to be the exporter has to you know: do this translation the it involves some cpu uh cycles to do this.

C

Involves a lot of cpu cycles, so we already do something like this in app insights, where we actually check every single key for the presence of a dot, and if this is not, we we effectively break it out into um multiple objects.

C

um I end up adding a config to disable that functionality, which resulted in a 20 to 30 cpu saving it's. It is a very expensive task, so to effectively write overseas and create what you're talking about.

D

There's an alternative, though, and I don't know how it will extend to the customer tributes, but at least at least for the standard ones, our semantic conventions yaml file could include, uh you know for each attribute. It could include a short name version and then, depending on a runtime flag, it will use the you know the original or the short yeah.

C

D

Yeah but you end.

C

Up saying, like add event, here's my properties and then you again gotta enumerate all over over those properties to effectively cut them down.

D

So yeah, but it will not be a runtime conversion at runtime. It will, depending on you know whether you're running in the context of a browser.

E

D

Back end, you would, you would use you know the appropriate key. You know you would use.

C

The long name or a short.

D

C

The application developer is going to be going okay, I'm going to omit this event and include these standard semantic convention names as part of the.

D

Semantic attributes is already a class right, it's already uh a library, uh and we are supposed to use that library. You know in the code. I.

B

I think there's ways uh to do this. I mean I I like I actually prefer, rather than like shipping a dictionary all that centos. I prefer your idea of in the semantic conventions just to find the short code, and then you just have it'll it'll save the footprint, also the client library, where, basically you in your code, you just use the content, the the uh constants, um but you have for um some libraries like the browser right browser sdk, the constants just map the shortcodes.

F

D

F

D

uh Case that it doesn't.

F

Cover is uh you know, customer defined attributes, yeah right then there's a question of.

B

You know how did they do that and I think I would kind of propose? Well, you guys should do the same thing, which is to find your list short codes somewhere right uh and to find a mapping, and so, on the back end we're in a collector somewhere down the pipe you you can map back. uh If you want, or just like just use short codes.

E

Yeah, I think uh I I think that works, and we have a president here in you know some parts of um uh our sdks as well, not application insights as well. uh The short codes uh just like what you guys were talking about, um there's there's a config that says use short names or long names. Now we we call them content blobs. uh We go and scrape the page.

E

um You know find out information about the content in the page itself, so that repeats so essentially, um each piece of content will have a name id the slot. It shows up- and things like that, so you can imagine um in a page like msn or whatever it is we'll have thousands of these content elements.

E

So, instead of keeping the names like in repeating so many times within an event, um they opted for a short name. So essentially it's you know they call it the data m attribute or something you could actually see it. If you go to msn.com you'll, you know, if you look at the network request, you'll actually see these things. The whole page is decorated. With these m attributes, um essentially it'll, be I n s, you know t whatever it is each it's a it's. It's a! So that's! Basically what it is.

E

You could decide to use the short names or the long names, but uh my question was going to be: what is your guys's proposal on who's going to do? The mapping back sounds like the back end has to do it, so that is a spec uh right. You know we have to let um that I I I wonder how that will work, because we have to speculate that. Somebody knows how to map that.

D

It's actually easy in our case in the open telemetry case, it's easy, so the um this mapping is actually uh in the spec. It's it's it. There are a bunch of ml configurations for each semantic convention.

D

The uh the whole definition is captured in the ml file and code is auto generated from that ml file, so the constants are auto generated. uh There is a library that gets generated from from these ml files, so the same library is supposed to be used both by the clients and on the receiver side.

E

Okay, so if we went that route, I still see the uh the dots and stuff existing like flat is what we would send out, not an object. It will be a dot b, dot c, literally a dot c, or something like that, as opposed to not click yeah.

D

um I I I don't know if that's still required uh so so one um caveat here is that you know these short codes are no more. uh You know possible right, they're, no more understandable by humans, like if somebody is looking at uh somebody logs this. uh You know json to the console and then, if you look at it, you know they are no more. uh You know you won't understand.

D

What attribute is what, unless you know you do manually, you know convert back to their names, so you can have like a single letter for the entire attribute name.

A

D

You don't have to have it.

A

I just want one question about that, like how would you prevent corrosion.

D

Yeah, so um I think.

D

I don't know, I think one option is that uh the short codes themselves are automatically created.

D

So when you build the semantic conversions library, you indicate that okay, this attribute, you know, I I need a short code and then the you know that that build that generates, that library will will have to use a consistent.

D

uh You know hashing mechanism across the different language implementations to generate the same short code and that will ensure that there are no collisions.

C

And for a custom attribute that the application provides.

D

Yeah that I don't know custom is.

D

um This is foot for thought, so I think uh yeah.

B

So so it sounds like uh just to keep it moving. We have like um two two proposals. We want to write up, because this is definitely something that should be an otep, um so at least the first half is just the straightforward part of let's just define short codes, a dictionary of short codes uh for all the semantic conventions and add it to the spec right that can just go into the spec as a yaml file. The same way, the semantic conventions are in their zml file.

B

um So that's like step one and then the other half of that motep needs to be. How should this be extensible um by end users like what do we expect them to do, uh and also how do you, uh how? How should we decode these? These short codes, essentially.

F

B

The collector plugin yeah, who should do it yeah it should go all the way back. um Probably it should be. You can do that or optionally you can. We will have to include a a collector plug-in that that does the remapping for people uh if they want want that.

B

um So I think that's all a pretty clear idea. uh I don't know santosh if you want to take a shot at just getting the first draft of that out since it's your idea, um uh but I think that would be a great thing to get moving on, because that seems like one of the next pieces we want to chip away at in this group is the overhead.

A

Okay, I do have one more question here: um does: uh does the is it gonna have to be some kind of change in the in the uh proto to indicate that you're using short names for the backhand? Now.

D

Router doesn't know right and the key value pairs is what protonates.

B

Yeah pyramid semantic conventions, yeah.

A

How would I know that the attribute value that it sees it's a short name and not not just a name.

C

It has to check every single one, you know somewhere the the cpu price has to be paid.

B

Yeah I mean th. This is uh yeah. It's probably that probably probably what you just said, nev um uh the the other way we could do. It would involve um possibly involve nesting, but uh that that actually gets back to an earlier point. In this conversation around nested attributes. One one thing I wanted to to bring up um santos. You were talking about switching to um using like nested name spaces like let's use like structure here rather than dot name spaces, uh we'll get extra hard pushback.

B

If we include that as a reason for wanting nested attributes to be available in traces, because that's um that that's a backwards compatibility issue right if we, if we switch, switch to doing it. That way not necessarily.

C

Like the exporters.

B

I guess I guess um I guess my suggestion, though, is nev like what you're there there's a there's, a smaller goal here for getting them allowed, which is look we we have these. These complex diagnostic objects that we want, and we just want to attach them, and we're allowed to do that now as logs, but we can't do that as trace attributes and that's really weird so like. Can we normalize that?

B

So I I just wanted to to point out when, when asking for that piece, I would recommend focusing on that use case, because that's about normalizing what we do and expanding it to include more diagnostic objects, yada yada.

B

If we wade into that conversation by saying, and also we want to like change around how we're doing the the recording of semantic convention stuff that that will just that will just expand the conversation into like more, it's just like stepping on extra land mines all at once right. So I.

F

B

Recommend like we, we try for the reasonable case there once we get attributes trace attributes, then, as like a follow-up discussion, maybe we could start talking about? Why don't we? We can start prototyping.

C

B

And talking about like hey, hey, is there there a better way to actually record these semantic conventions? Was this this flat style? Actually um not not the best way to do it, because.

G

I know there's actually.

B

A there's a lot of strong feelings about that. There's like another camp who thinks the the nested approach has has a bunch of different problems, potentially um so yeah.

C

Name collision is going to be one of them um and someone is going to complain about that or someone should complain about that um and that, if you have a you know, event nested object and then you've got all the event. Dot values, you've got name collision.

B

Right you've got a lot of object. Merging that happens later anyways. My point is not that it's wrong, but I I hope just right, just as a practical suggestion um to not not mix those two uh use cases together uh when asking for for what you're asking for now, uh but also my point is: if we're doing short codes is actually neither here nor there right, like the nesting, is like nice.

B

But if we're like actually doing like space savings through short codes, you don't you don't need the nesting anymore for for solving that problem, that that doesn't mean a nested approach. Isn't nice or better? It's just. uh We don't need the nested approach to make a case for uh story, objects and trace attributes, and we don't need the nested approach for space savings through short codes.

B

So I would just make sure to to keep that as like a third third separate issue, because just because I know for a fact that that was like a huge contentious debate earlier in open telemetry's history. So we don't want that to get in the way of like these other things.

D

uh So to take this topic forward, nev uh would uh our ram. Would you guys have uh um the bandwidth to um take it to the next level? uh Work with, uh I mean create door tip, uh because I I, after this events, api, uh I want to start working on the resource session. Id is at the resource level. I I want to work on. I want to get deeper into that because I think that's a you know slightly bigger one, that's blocking the ram as a proposal right. I think so.

D

I I want to take that up and um uh I posted a link in the chat where I have listed a whole bunch of uh things in consideration to improve the rum's performance.

D

So take a look at it. It has multiple options, um and this way this topic that we just talked about is one of them.

D

So so, if you are able to do compression, for example, you don't need to do any of these things right. I think you can live with. You know long names, you know repetitions and all that so for the mobile case it is, you know, compression might be an option only for the browser case. You know it might be a concern, uh I don't know it just just as an example. Yeah.

G

That is the case like uh if you're running in an electron environment, then.

C

G

C

G

Gzip library.

C

Because you're effectively a local client with a mobile, it really is for a browser. Cpu and size is a problem.

D

B

If compression is an option.

D

Then session ids could be repeated at the you know, your attributes can be long name, so none of them are a requirement right. I think.

D

E

F

D

We should go with the assumption that we won't be compressing, which is uh there's a good chance.

B

Yeah uh so I'll all put together in otep for ephemeral resources, which is what I'm starting to call these things uh that we want uh I'll put that together this week uh and propose it at the next uh meeting, um because I I think I think it's an important thing to have basically beyond. I think sessions has just pointed out that we we're missing a piece here uh and we're gonna want to use it for other things.

B

But if, if that gets totally shot down, um then I guess we're back to stapling these onto attributes everywhere, which which I don't like but uh yeah. It would only be the browser where this is like a real serious issue, but that's like a really big. Only.

B

Given like how huge the browser user bases well,.

C

um It's probably not just a browser like javascript in general, like even if you're running um in an electron app and it's simulating a browser case during unload you're, probably only going to have send beacon and you have a hard limit of 64k that you cannot send anything larger and it's not just a single event for 64k. It's your your total outstanding payload.

B

Yes, it's yeah, it's the it's, not just the the key size. It's it's the value size which we won't be compressing with short codes um anyway, anyways. uh I I.

G

B

Sorry, I just want to say I have to run in a couple minutes. I have another meeting at 9 30, unfortunately, um so just want to say that sorry go ahead.

A

I was gonna say it's probably it's probably an issue in mobile applications as well, because if it affects uh data usage, yep yeah.

C

B

Bandwidth devices I mean once we have all these like space savings in place, don't be shocked when, like all the other user groups, start wanting to adopt them because, like why would I why would I intentionally use the like more inefficient version of this stuff.

D

So compression is the only uh response. If compression was not an option, then yeah.

B

Yeah yeah compression's nice, but you know there's plenty of places where we uncompress this stuff, like in the collector. You know what I mean right and if the collector can just operate on short codes, um you know that's a uh performance.

A

That's a lot of space.

B

Memory savings potentially like around number yep.

C

So uh oh gzip, yeah, uncompressing gzip, is actually quite fast. It's it's a constant.

B

Yeah just more like once you've uncompressed it, the shorter strings are less memory space. I'm.

E

B

See like the actual bloat uh that you reduce in, like a fully um uh a fully operational production, collector dealing with.

D

How many events.

C

Are like, if you have a bunch of one events, no sure? Okay, um if you have two, maybe once you start getting above two, that's really what you like.

B

Which is a another um that that's like another fun project for someone to do uh often, when we're trying to do performance testing on open telemetry? The question comes back of like well. What shape is this data? In reality, uh I think uh the demo group is putting together like a realistic giant hotel app based on like kind of hipster shop, um so we might be able to use something like that to capture something akin to like a standard hotel, payload but yeah. Just.

E

B

Actually, a question that comes up all the time when we're trying to load test and think about what optimizations to pursue is we don't have a clear handle on what what is what is the bell curve in terms of data shape.

C

So yeah and- and it depends on your runtime like for a v8 browser once you get an object with more than 22 keys just enumerating. The keys is like uh three times as long because, because v8 has all these optimizations for internal lookup tables for objects.

B

Things like yeah.

F

Yeah, okay, um I have to run yeah. I have to drop as well uh I'll, see you folks tomorrow, yeah all right. Thank you.

C

um So in terms of uh what santosh was asking for ramirez to to do, which bit, which is what I to clarification on, um what was your take fun, I I I wasn't calling.

A

Yeah, I think he was asking like if you could, if you could um maybe work on the otep, for the optimization for the short names.

C

Yeah, I I'm not keen to put for the short names it's.

C

It's complicated, I've worked on this before and it's it's messy and it's.

A

C

In terms of bandwidth, I'm probably not going to have it this week. I I have this is my release week uh and it's part of release week. I do like seven releases, so I'm the next couple of days I'm release, notes and npm packages and consuming said npm packages. So I'm probably not going to have it done before next week um and the stuff ram was talking about that. That was uh effectively domain specific. So that was uh what msn do offer their own things and then consumer on the back end.

C

So, okay, okay, um and that in those cases uh a bit like um well, actually one identity, the server decodes it. But in the case of msn I believe they. It goes all the way to the back end and then the back end system interprets those but yeah having it dynamic.

C

Is the only way to avoid game clashes, but it's uh it's problematic in that you've got to pay the cpu price at the point of encoding it, which is on the client.

A

So by when, by saying by dynamic, do you mean uh that the server actually has the dictionary and like looks up each name like? Is it in the dictionary? If, yes, that is the short name, if not, then.

C

He was talking about how to create um avoid name clashes, which means at the point of recording the event. You have to enumerate over the keys to make sure you don't have duplicates, and then you assign the values. You can have a fixed set of assigned values, but then you have to have that lookup table on the client as well, which then code space you better so yeah it does result in a smaller payload.

C

That's definitely the case, and in some cases that's what you have to do. You're like if you're going to include this in cookies. I would be 100 behind that, because that is the only way to reduce cookie size and cookie sizes are even more problematic than than send beacon, um yeah yeah, but yeah.

C

A combination of short codes and and nested objects that also that also helps. But uh I I would prefer to be pushing for nested objects rather than just saying short codes.

A

Sorry, are you in so? Are you in favor of the short codes over like we also discussed uh having like a single single attribute value that has stringified object, like? Are you in favor of the short codes solution over.

C

Well, and just saying it's a nested on the nested object is a json certified version.

C

If we're going to go that, then we want the shortcode, because stringify.json is actually not as efficient as it could be, but uh in terms of transport, that's what we have to do when we get out the door. So the combination of the two in the end is probably the way for the fixed set like having um okay.

C

We have a lookup table having the semantic convention so that for the browser, you've got the minified name um that you populate sort of works, except if an application developer goes and defines their own strings because they don't want to consume the object that contains all the strings.

C

um Again, it comes back to minification like I would not want to have the semantic inventions in a namespace which is ideally what you want to do, because you want to keep all the everything namespace together, but if you're only using one of the names out of the semantic conventions, you end up got that you've got that entire object in memory.

A

C

It can't be pre-shaken so.

C

uh It's like cpu or memory, which one do you want to like use the most or the least, if you.

A

Trade off right.

A

I have a separate question for you, um so I worked on this um on this events. Api prototype.

A

Yeah and- and I was wondering, do you think it would be um like I'm trying to figure out how to how to continue making progress?

A

uh You know, I think we we have we're going to have a lot of oteps out there, and I you know, like these discussions, take a long time and I'm I'm wondering like, if there's a way for us to to actually make progress uh in kind of experimental state where we could build some of these things, and you know, have them be an experimental where people could start using them and give us feedback.

A

um You know instead of waiting for these, uh you know these specification discussions like to settle which could take months. uh So do you think, like that something like this with this events, uh events prototype? uh It could get merged into the js repo as experimental.

C

Daniel's, pretty good in in terms of letting experimental stuff happen, um because there's no spec we could get pushback on that. um I, what I'm trying to do is effectively carve out time in in june to really start generating a web version of the js code, which the more I think about it. The more I looked into it. um It's going to be big. um It's like.

C

I part of the issue is we need to cap everything as interfaces and then effectively you use more or less the composition model so effectively. Instead of having classes, you say new class, we actually want to have functions. That say, create me a thing that looks like that. If I correct me that interface, um so the stuff, that's not used, gets dropped when it gets tree shaking um and then there's a whole global scope thing. It's um yeah, I'm concerned with the amount of code I'm putting myself up to write.

A

Well, I I so I when it when it comes to implementation, like I'm like. I can dedicate time to that, so I can I'll definitely be here to help that.

C

Yeah, um and at the moment I don't know what, where to store this thing, I notice you put yours in your own personal one. um I have to talk to ram to see whether we can carve out a microsoft space for effectively investigating the uh a web.

C

You know a smaller web version because, unfortunately, until we hack and munch and fix most of the the core code, it's uh we're not gonna know what the sizes are. Gonna be right.

A

C

Too many classes and name spaces and expectations of the api, um which I tried to push back on like well when I, but as by adding the diagnostic log, I got so much pushback on trying to implement some of my stuff that I then started. Calling me the minification of nazi.

C

And the diagnostic logging end up being different to what I originally proposed, but it is what it is.

A

So so do you think, do you think it does not make sense to to implement anything in the js in the current js repo.

C

My plan would be to make this thing: api compatible.

C

I am just a little concerned about your throwaway work, but I understand where you're coming from in terms of is that throwaway work? If we've got nothing, so we can't prove the direction we want to go um like I know, bogdan's very, an even pigeon to a certain extent is, is very keen on seeing multiple language implementations before approving a spec wow.

A

I mean, and the reason is also like we have we have. There are people out there. We have customers like who want to use the hotel, yeah vhs for browser right now, and you know they're, okay with the overhead. You know, maybe they don't really understand it, but um but they you know they're using it. People are people who are using it and like if we, if you continue like you, know the spec work and the implementation of a completely new sdk, I mean that could take like six months.

G

A

So um you know, does it make sense like to have something for people to use now or sooner.

C

Yeah, I guess if, if we have the basic event api and then we can start flushing out the I don't like the name but cementing conventions for what the events look like. um Like you look at the moment, there's a what's. It called uh there's an ex a package which implements document load so affect your page load event and it takes it into a span today.

C

um I think bart originally created it. um That's partially, why? I want to see the attributes unified between logs and traces so how an event gets out. The door is really just the transport and you can just tack it on to the appropriate place, but we need to have those semantic conventions, because right right now, our backend team have the equivalent of a collector but they're only effectively handling uh server-side events, uh server-side traces um and metrics, because we haven't defined what the events look like, and and how do we send client-side events?

C

um Okay, so they're the areas I'd be I'd prefer to be concentrating on rather than the short names, because I think the short names can come later. There's an optimization um defining what what the events look like in their shape.

A

What I was thinking like if we, if we you know, we have like lots of things in progress and like we also started working on on somatic conventions, and we know that we need that. um You know I think, having having something working like that, you could. uh You know as we as we, for example, as we discussed some of the conventions for document load, uh we could actually prototype it right and add it add it onto the events, api and people. Could people could try it out?

A

C

And start using it yeah yeah.

A

C

uh I I guess, let's talk to daniel tomorrow um and see what his thoughts are in terms of you know. Do we do it in the country repro, or can we just have an experimental package in the um in the main js or any other suggestion you might have? Okay, okay, yeah.

A

Yeah the the con- I guess, like the contrib repo, is like uh there's, probably not a lot of a lot of restrictions. There.

C

No, no and things have migrated from contrib to the core before so again,.

A

Okay, yeah, I I left it. uh I put it in in, like the main main repo, because I expected we might be changing some some core, some other core packages, but maybe not.

C

um I, if, if, if out the ultimate goal of having us use logs or spans as as the transport, then in theory we shouldn't be changing anything um except that attribute that the f3 value instance, which is where I dug into last week, um it does restrict to like your strings numbers arrays, um so it will not handle nested. Today, yeah the span attribute expec the span attribute value x. Effective is just an alias for the attribute value.

A

So yeah yeah, okay,.

A

Yeah, I think I think you're probably right, there's probably no need to change anything.

C

At least initially, um uh you know at some point we probably will, but at least initially we should. um But it's like you managed to have your prototype off in your own repo. So uh did you have to change any of the core js.

A

A

Okay, um yeah, we can so we can ask uh danielle tomorrow.

C

Yeah um yeah I'll talk to ram because we have a stand up in about an hour um in terms of. If there's you know a name space environment we can create because we're in terms of the open source projects we can create on github, we've got a little bit more leeway than we do now.

C

um We can always like stand up something there, and then I can give you access to drop anything to that too. Okay,.

A

Sounds good yeah, um the other topic just to give you a heads up that I wanted to discuss today, but we can go to it tomorrow, is related to semantic conventions like I was wondering how specific uh the semantic convention should be. um You know like. Should it be like? Could we have would we have something?

A

That's like semantic conventions for like all types of interactions that are shared between browser and mobile, and then you have like sub attributes that define the type and and the details or or do we want to have like very, very specific types of uh types of events that uh are like browser-specific mobile-specific and not click-specific or touch-specific.

C

um No, I I like the the earlier thing where you've been describing it as an interaction event. I think that's, that's probably the level you want to do it at and then you know as part of that interaction. One of the attributes would be. This was a click event, so they think that they could touch whatever else, and then we just define the the optional fields of the optional set of fields that we would we expect, um and then we still have you know a generic bucket that people can put their own in.

A

Okay, yeah yeah. I think the interactions are like the ones that, like clearly are uh special.

C

Yeah like, if you look in, I think last week, one of the meetings I posted, the the github click analytics yeah yeah,.

A

C

Yeah, like that's effectively just one event um as far as the spec is concerned, but then you have all the optional fields, the that define the type like the the behavior thing that I that I posted there at one point is just you know the values for one of the fields.

A

um Yeah, okay, yeah, it makes sense like I I wasn't sure because I it says, like the name says, click analytics. So I wasn't sure if it applies only to click um click advanced. You know it's.

C

It's mainly driven by clicks um because that's the event that it listens to, but you you can implement hover events and and stuff like that. As long as the event bubbles up, that's really what it did.

A

C

But yeah it just boils down to. Was it a page action or an action event um when it goes out the door, so, okay, the equivalent of what you're calling interaction? Okay but yeah? I I don't think we want to say mobile browser whatever I think tigran keeps pushing us down that path, and I I don't want to get in we're going to have an explosion of event semantic convention time. I guess not where you want to go.

A

Exactly exactly yeah, I see like different people like mentioning that I'm like showing examples, and so I think I would like to discuss that.

C

um Because yeah we've talked about like the source, um which I think is how we end up getting down that mobile path uh before so. I think one of one of the one of the generic fields of the event is going to be who's supplying this and I think you've already done work on the browser, definitions and stuff like that. So I think that's the level it needs to be. Actually we talked about device. I think it was.

C

Was it last week, um sorry so yeah uh the the device you know in terms of identifying the devices, but that, from my perspective I think that's just really the source of the event and that's just decorative attributes for that source.

A

Right right, yeah.

C

um Yeah, can we do it that way and then do it based on composition or do we just have a single thing that says event source and then we define browser mobile device, generic or whatever? I don't know um so. I need to have that time, maybe ram. I think he said he was going to be more available this week.

C

um You might be able to get someone from there. Probably can't get anyone from python or java java to help us in the short term, because they're working on a whole bunch of other stuff.

A

C

Long term, we probably can't, but I think we're only a fairly small team really.

A

Okay sounds good. Well, thanks for the discussion um cool, so I'll I'll talk to you tomorrow,.

C

Yep and you have a good day.

A

You too right bye,.

C