 Lord. All right. We've got a small nucleus of folks for our community call this month, but we thought we should still record something so we can have an update. So again, I'm Rick Johnson and I have Jeff Spees and Ryan Mason and Cam Blandford on the call. So just wanted an update and keep moving forward with our updates here. And there is one reason we wanted to share this is we have made progress of having some sample things to start as a baseline for working with Share Red and Node Red in general. And then from there, we're looking to start to pull together some more community activity and we're thinking about having a community sprint possibly in the near future, April May timeframe. And we would love to have one or two more people be able to pull in who's able. So we're so likely to be putting out a call on the Discord channel as well. We did that, but we're really thinking about how we can start to prep something to then move on because we do have some good work to do still that will really benefit from a couple more people being able to pull them in. So first thought would have Cam give a quick overview of the Share Red node example repo that he created. And then the initial ideas that can be baseline where anyone can fork that and do that to create a new custom node within Node Red then have that kind of be a building block as we move forward here. So I'll relinquish control of the screen sharing here and let you take control, Cam. Sounds good. Okay, so this is the repo Share Red node example. And basically all this is a template for making your own nodes. So what you do is you would fork this and then as the documentation says any place example dash node is written, just replace it with whatever you want to call your node, make sure it has a dash in it. And then if you go into the example node JS file, you'll be able to see the actual logic that's happening here. So the node on input is kind of like where you really want to or where everything's going to happen. And it's like relatively simple. I mean, this is just where you're going to take your input and then pass your output to and the comments kind of explain that. And that's basically it. And you can just go through and say, you know, you wanted to make any sort of like a unit like an addition node, you could just pass two items into it, look at the payload and add those two items together and send it into the output. It's pretty simple. The other files are for mostly formatting like what the node actually looks like. And for like sort of configuration of the node, for example, this is what the detail slash options window for the node looks like in HTML. This is just sort of what the tool tip is the description. And you can add an icon for your node by putting it in here. And there is a section where the fact that the node is in the share folder is described or in the share subcategory is described. But that's not I think at this point that that doesn't need to be changed. So really, you're just updating any instance of example dash node to what you want your node to be. And then add in the functionality in here. And that'll rename the node for you and everything. Any questions? So I think one of the things I would be good to mention. So I think you hit upon the main points that were someone would take it and then modify. I can probably show how I have gone started going through the exercise of forking this and take a look at this. Let me just take me a second to open up where those are since this is spontaneous. Because there really are only so okay. So this would be good enough, I think. Let me take control here. Okay. So I was starting to create this node called share property mapper, which essentially it's fairly simplistic in the idea where you have an input property name and then output property name. So thinking about how you might want to map one metadata field to another field within a schema and then you have an input object. And this is the part that I'm most experimenting with is how to have it be configurable to be able to grab a particular part of the input object that's coming in. So if you're we've probably talked about previous calls about there's come very common one is you're working with a message.payload and that's the object that typically gets passed around. But there are other things that could be done where it could actually be hard coded to say this is actually an input value that is then going to this or it could be pointing to a particular buffer, environment variable, et cetera. There's other things that you can do within the flow itself, like if you were to store a property within the memory, you could put it in this flow memory, global memory, et cetera. Okay, so enough about that. So in terms of creating this, it's actually pretty simple. So in looking at that, I ended up just renaming a couple of the files. So there was the HTML file and let me actually probably would be useful to pull up the GitHub example there so we can compare. So if we look at, let me just go straight there so I can find it faster. There it is. So share read node example. And so there was the example node HTML, sample node at JS. And those are really the two core ones. It's pretty simple of what I, so I renamed them to be to map to then the actual node title. So share property mapper HTML, share property mapper JS. So then looking at those, let me open it up in the right. I personally like Emacs. So hopefully this will open up here. Oh, it was, this is what was hanging when I was trying to fumble before. So I will try just go to text instead. Go. There we go. Finally come up. It is not coming up. Let's see here. There's stuff here. Okay. So I don't want to start there. I think I want to start with the HTML because it's easier to start from there and then talk about how that maps to various things. Let's try this again. There. Okay. A little bit of creativity to get this show up. All right. So the HTML file, as Cam said, this is basically the guts of it where this is where it's defining things like input properties that I've played around with. And then defining how it actually shows up in that configuration screen that I showed. And then the JS file is typically then what happens once you have data itself looking at, let me get back to it. There it is. What it is actually going to do. So you can see I've, this is not very clean. So take that with a grain of salt. I have a lot of things commented out, uncommented, et cetera, as I've been playing around with this. But essentially, you have, and what this is doing, it's taking an input work and then doing things with the message.payload. It is taking input property, output property, and this is all code that I had working and I have been commenting out as I experiment with various things. Then looking to see, to building some things where it's testing, is this input thing in array? Is it not? Output it, map it, and then actually push it out. So the anything, essentially anything that you'd want to happen once the value is input, that's what you'd put there. So I think this is probably a good time to go back to the example that is in here and compare the two, I think, because that would be the most useful. So I'm looking at this one.js, as Kim said, it's pretty simple, where it's taking the node input and then just whatever it gets, it's pushing into lowercase. So I just showed a more complex example where it's actually looking to traverse an array and grab some values and then push it to a new object. And that is all in thinking about how we could have an input configuration of properties to an output property and have, I think, yeah, I think it would be useful to pull up the, this is where I just rebuilt my machine, had my machine rebuilt, so lots of things are that were open before and not open anymore. Let me open those up. Yeah, Emacs is actually the first time I've tried to use Emacs since I rebuilt it. Well, let me go back to here. So the example that I wanted to show is actually, I think I can just go to GitHub and do that. That is best since I've checked the code in. So if you look at the share red flows in the harvest flows, this repo, there's this mapping file. So this is what I'm working off of and building and looking at this node is thinking I may have this input property of kind of arbitrary nested level and then going to some other arbitrary nest level and how we could just have as much as possible things coming in as a configuration file and then mapping the various things. So this is the first step of that building block. Cam, Ryan, did you have anything to add clarification purposes? No, I think you did a really good job of covering it from what I can tell. Yeah, so as you can see, this is in progress and we'll have a more polished version of this. So the goal is, I think, as part of this is I've been working just to have a, now that we have the repo that can be forked to creating a node, have kind of an end-to-end example of how that is done and document that is the next step for us. But really going back to our list, let me find it in our agenda here. You can see my many tabs open. There it is. So we have this initial set of nodes that we might want to have as kind of building blocks or building various flows. So parsing names, being able to branch different flows. We could see potentially having like an OAPMH process being kind of wrapped up into a few different nodes. So that is not something that, that's definitely not something that someone should have to recreate every time, since that's a pretty standard process. Loading things into CSV, these are some things that we have in some example flows, but we could wrap those up again so that there's less coding that someone might have to do to use these. So I think that's the biggest update from kind of the share write node example. I can give a quick kind of institutional update from Notre Dame standpoint. We have also been looking at how we can pull in, how we can pull in data around centers and institutes on camps here, then to be able to have some kind of general gauge of relative impact. So relate to that, we've been pulling a metadata data and we do have a dashboard similar to the one that was created for TridentShare that is in progress. So that is something where we're willing to share to potential leverage. And I think the other community share update is, and this is more kind of an FYI of things to look for in the future, is shares also been involved in the PresQT grant that has been going on at Notre Dame among partners, including San Diego, Purdue, HubZero, National Data Service, NDS. This is where I'm going to be getting myself into trouble not remembering all of the partner names. There's ReproZip, quite a few others, MetaDig is another tool that has come up, but we potentially see a place for the share manipulation tools that have started to build within that project as well. So that's something just to kind of look for in the future. Is there anything else to add, Cameron and Jeff, from your standpoint? I think it covers all of it well. Yeah, I think that's a good summary. Okay. And so I guess kind of like looping back. So we would love to have a plan in place to start planning for our community sprint. And I think the best way to go about it is to start really doing that grooming of the backlog to see what we could pull into a sprint before we would actually execute that, pull some people in so that then we could be pretty organized when we actually do the real sprint in and of itself. So that is something that we will want to share in the near future. And we will do a call out for folks that may be able interested depending on the time and if they did. And I think first those that are interested and then looking to do a match of availability of when we might schedule that. But we do have some interesting things happening from the standpoint of one, just we've just been talking about these flows to date for this call in particular. But there's also portions around if we have different metadata harvesting flows that will be scheduled or running from time to time. There's work beginning around how we would manage jobs, any kind of cues around that, how the data would be persisted, propagated across different instances, really thinking about shares newer architecture as being more decentralized and being able to have a local instance of share that may or may not be connected to a network of other instances where we're not thinking that it's required at this point. So I think there's some really interesting work that we have that we can queue up here. If Jeff and Ryan and Campbell have anything else, I think we'll probably maybe call it good for this update this month. Yeah, it sounds good to me. Yeah, that sounds great. All right, where should how should people contact you if they're interested? Yeah, so the the best way so you one you can email me. So I the rick.johnson at nd.edu. I'll just type that into the agenda here in the video. So so that is recorded for those purposes. And there is also this discord chat channel. That is another way, but probably just emailing me is probably the simplest thing to do. If folks are interested, but we will be doing a call out to those that have already been engaged in conversations to see if they're they're able to to join anything coming up. Okay, very good. All right, so thank you all for those who will be watching in the future and will be updating soon. All right, thank you guys.