Live CEOing Ep 705: Language Design Review of ServiceDeploy continued

Okay, everyone, we are doing a live stream about functionality for version 13.3 of orphan language. We're specifically talking about the service deploy functionality, second of a series. The basic idea is that service deploy is lodging what is essentially a callback, an API function to be called back from, from an external service. Is that correct?

Not necessarily. Because the two services that do implement service deploy interface right now don't implement a callback. They're basically like kind of some kind of mini clouds you run on your own hardware. And so there's no callback there, it's just an API.

Okay, so is it right to have a single function that does this? I mean, one thing to do is your service deploying an API function. Is that. But in all cases, your service deploying an API function, true or not true or scheduled task or something, is that correct or is that not correct?

It's not necessarily an API function, but yes.

Well, what is it? What else is it?

I mean, it's, it could be a URL dispatcher, a form function, whatever.

All right, but it's one of our static page.

It could be a static file, it.

Could be any expression, right?

Yeah, yeah, pretty much.

Any expression that is lodged with an external service.

Yeah. For some definition of external.

I think it depends on the service. Right. Like, I mean, there's some services where, you know, you can host basically arbitrary, you know.

Yeah, I'm sorry, we had corrected this wording. Why is that not showing up here? We made a change to that. Why is that not showing up here? Right. Remember that?

I don't, I, I, I, I remember that.

We didn't like the anonymous.

Go back and watch the freaking video and make it the change, please. Yeah, this isn't right. Fix it. I'm gonna, I'm gonna overwrite this file then. In fact, unfortunately, because I didn't update documentation, I might overwrite other files, so I probably shouldn't do that. Please, please make sure that these things are actually executed.

Yes, will do.

Okay. All right, so let's go over this again. This is. Okay, I'm going to start making my own notes here. First version of this notes is from 2019, so this is the second part version. Okay, so let's take it from the top. Service deploy, it's not a okay to a service. Right. That's the destination service. And. Okay, now you have this thing, what we talked about last time, and fixed yet, Right? That doesn't make any sense what you're saying here. We talked about that last time, didn't we? Yeah, yeah. Okay. So why is it still there?

You didn't change it. I just went through the video. I don't see the edit.

We talked about what it should be. We talked about what it should be.

Yeah, but Stephen, at the end of last meeting, we weren't sure that we're going to change the argument structure to this at all.

Well, we were certainly changing the wording because the wording doesn't make any sense.

But this. But there's. There is an older wording.

Doesn't make any sense. It needs to be changed.

At what point is that? The dogs are out of date, even by last.

Say it again. Okay, well, so when I update the documentation, I'll see it again and then I will push back changes.

Okay, wait, wait, Steven, the point is, this is a proposed change for. From the service deploy notebook that is in the WAS packlet.

We.

So since I'm working on Wolfram Web Engine, I want to make that less just was and make it work for other things, including Wolfram Web Engine right now and maybe something else in the future.

Yes, okay. Right.

That was my proposed change.

What was your proposed change? I don't understand what.

The document. The document you just closed was my proposed.

The documents you just closed are not acceptable documents.

Okay?

And we went through that last time.

Yes, but if, if, if the, the zero hypothesis here is the null hypothesis is not to change anything from what it is right now for more.

That's not going to be acceptable.

But that's what we were floating at the end of the meeting, that the argument instruction didn't need a third argument.

We're not talking about the argument structure. We agreed that the documentation was not right.

Documentation isn't right because there's no design.

If we don't know how many arguments this function have, how can I write the right documentation for it?

Okay, all right. Well, if you'd given me some notes from last time, it might have helped. Right now this just seems like a time waster.

I did shoot off in an email the notebook. That should work now that it's opening on my machine.

Yeah, I see it, but I think.

There'S a chicken in the egg. You know, either the docs have to come first in order to, to look at the design or the designers come first.

No, I know, I know, I know, I know. That's fine. So, but let's, let's go through what it is we're trying to do here and let's not get confused and let's not talk about really kind of annoyed that we don't have the stuff from last time here. That's really not okay.

I'll make sure that doesn't happen again.

Okay, let's. Let's go through here. All right. Is this still what it was last time? Yeah, everything's still what it was last time. Okay, so we have to start from scratch, basically. Okay, what are the services that we are currently planning to support for 13.3.

Was and Wolfram webengine?

No, that's not right. We've also got other things we know. Okay. We've got those. We've got the. The OpenAI AP open AI stuff. Right.

Which.

Am I wrong?

I mean, which doesn't support service deploy so far. We can make it.

Yeah, that's what I'm saying. So, I mean, let's discuss what it is. You know, targets. Okay. We've got or from application server, And that's deploying APIs, right? API function, etc. Is that correct?

With anything?

So it includes a file. Yeah. Okay, next.

What's the next web engine?

Okay, and it's the same thing, right?

A bit more than was. Because specifically what, for example, was done in support URL Dispatcher.

Why not ask Andrew?

I was never ticked.

So. So, Aubrey, please find out.

I. I strongly suspect it's just a bug.

Okay, so Aubrey got it out. Find out. I don't want to hear it's just a bug. You can get it, then get it fixed.

But then there's a. There's There's a number of things. Like some interpreter types don't work on was. It's. It's weird.

Okay, so let's find out why. Okay. Another is another thing that we had, right. That we talked about before. Now what are the other ones? We've got bots like the Telegram bot. Is that correct?

Not in 13.3.

I understand that. I'm saying targets. That's what I said here. Right. Let's go through what we. What we are planning to do or what we are thinking of doing. Okay. Alexa skill. I don't know if Alexa is still alive, but we'll find that out soon. Okay, we've got OpenAI plugin.

ChatGPT plugin.

We've got. What else do we have? We have Telegram bot. Potentially, we've got, I don't know, a.

Slack discord and slack bots.

Okay, all right. Discord bot, slack bot, whatever, other things like that. Okay. Anything else that we know of. So let's look at what the typical thing we need for these are. So a mail receiver function that's actually Its own thing. So this really should say mail server because that's what it is and what it. What it is trying to go to as a mail receiver function. Am I right? Do you see what I'm saying? A mail receiver function could be. That's the thing that is called with certain arguments by the mail server. Is that right?

Yeah, I'm just confused about just calling it a mail server because I don't think you can. Like we went through this the other time. You. It has to be the cloud mail server, not just any old mail server.

No, that's not correct. We went through that last time. It's not correct. What it has to be able to do is to lodge an email and it has to be able to install something or whatever it is, the proc. Mail file or whatever it is that says run this code, which is an API in the cloud on this piece of mail, on each piece of mail that comes into this address. Do you understand what I'm saying?

Yeah, you're saying that a general feature of mail servers is that they allow you to assign some code to be executed or something.

Exactly when and what has to come back. Okay, is right. And so this is. We went through this last time. It's a disappointing. We're having to go through it again. You know, right now we have implemented this for the cloud. For the mail server in our cloud could be implemented in epc. It could be implemented in another kind of mail server. Am I making sense? Does that make sense? Do I need to repeat?

No, no, it does make sense.

Thank you.

I don't know the technical details of.

Okay, that's fine. I'm trying to get a design that. Where we actually make forward progress here. Okay, so now for. For, for example, the CHAT GBT plugin, the interface is API function. Is that true or not true or it's rather a URL disp.

I don't know what you mean by that, but I mean like there, there's. I don't think like. Okay, right now it's its own thing. It's a ChatGPT endpoint or sorry, ChatGPT plugin object. In the future it might be possible to stuff it into an API function or something.

Maybe it isn't a good idea. Just like mail receiver function isn't an API function.

Yeah, I think it's more like that.

But yeah, I think that in general what you do is like just. Just like Todd did for Alexa skills. You take a specific. Have its own head or might not and then turn it into one or More API functions. That's why you need a deploy function and not just an.

This is saying we've got two different things going on here. So if every one of these has its own custom, you know.

Well, I think it's just, just as when you call service execute different services, expect different kinds of arguments, similar.

Okay, but so let's discuss what kinds of things go in here, because these ones have communal garden symbolic objects. Am I making sense? Yeah. Whereas this one has its own custom exotic plant.

Well, I think it's basically the first two are services that happen to be able to display basically any HTML. And so that's why you can, you know, why you can do these fancy things. There are other ones that, that, you know, like a mail server doesn't, you know, it's not, it's not displaying HTML, among other things. And so, you know, there are other things you can deploy to it.

Right.

Honestly, the first two seem like they're probably the outliers and that they're so flexible in their inputs.

Yeah, well, the question is, I mean.

I expect all the other ones, you know, there's going to be a discord bot object or ideally not exactly, but you know what I mean.

Right. But if that's a symbolic wrapper, that's its own name. That's something we have not done. Not for, you know, service execute, not for import, and so on.

What about.

Didn't I see something? I think that for. Well, I mean, one thing that was clear to me while I was trying to code up the Telegram bot is that there is a situation where you want to deploy an API function which is an API function, and it doesn't get messaged into anything. So I think that some of these would support API function, especially like the Telegram API changes very often, and so there might as well be things that you can only do if you code the API function that's the web hook entirely from scratch. And you know, things like what the Alexa skill does, which messages the arguments into an API function is a convenience that sometimes you get, but not necessarily you want to get sometimes.

I'm sorry, I'm totally confused. Look, what we're doing is we went through this before. I. I'm disappointed that we're going backwards here. Right. Remember these hierarchy. Okay. We have a service type. Okay. So each service type, presumably associated with a service type is a, you know, has things you can deploy to this service.

Absolutely, yes.

Okay. So each one of these services has a certain set of symbolic objects that can be deployed to that service. True, yes. So let's decide, for example, for an Alexa skill, what do we want to do here? Do we want to have an association which allows you to specify all kinds of key value things that might change as the Alexa skills interface changes, or do we want to do something different where we package it up like a mail receiver function?

I'm not sure about the mail receiver function analogy, but in the case of an Alexa skill, there's a bunch of information that you have to, that belongs to the Alexa world that you have to specify to create a skill. Sometimes normally you do that on the website, but there is a way to do it programmatically nowadays and you could imagine that the service deploy to Alexa could package up all the information you need to register with Alexa for your skill in some huge association.

Right.

That's, that's, it's an imaginable thing.

Right. So the question is, do we want to have custom names like this, right. Or do we want to have an association there? So Christopher, can I look at what you have for the. Is this, is this. Where's the thing that is the ChatGPT endpoint?

Scroll down on the, on the notebook on the right and there's links to the packlet documentation where on the bottom.

The first one, though the second one, the API functions, I think isn't quite as flexible as it needs to. Ignore the packlet symbols.

Well, wait a second. But, but what would you do if you were doing this with associations? Could you. Would it be reasonable to just say service deploy chatgpt plugin or something and then here.

Yeah, you probably could. I'm thinking how you would do that. Yeah, you probably could construct it with just associations.

Yeah.

Some of the value of having it not just be associations is the fact that, that these things support like sub values. So like if you have the endpoint object, you can get stuff like, oh, give me the API function that this endpoint will be turned into. But that's, that's only useful for kind of niche cases.

Well, okay, but maybe it's better to. I mean, one possibility is every one of these is a packlet, right? Every one of these, the thing, it deploys the packlet and you really expect to have these external symbols in there because we definitely don't want to put in the system, you know, right. This week's, you know, yo.

Well, it could be some kind of service. I mean, I think service object is taken for something else, but it could be some kind of service object esque thing. Um, but yeah, I mean, I think, right. Like in this Case. Yeah, I think it probably could be just an association. Yeah.

Okay, but is that the general thing? I mean, in, in my. I mean.

Okay, I mean, general anything can mean associations just.

No, I understand that, but it might be an ugly thing.

Yeah, I mean, look, I can try and. Let me see, I'll try and convert this one to an association, see what it looks like.

Okay. Okay. I mean, it'll probably be nested associations, right? I mean, this would say.

Yeah, it'll be many levels. I'm just gonna see if I can format it in a way where it's not like totally incomprehensible. What's going on?

Okay. All right, so, all right. First level is the service type. Second level is the server, the specific server. Now what's deployment instance? Remind me what, what's an example of that?

Deployment instance is like. It's like what the cloud object is for the first two, like where you put this thing and how do I reach it as a URL for bots, it might be which specific bottom, like either the name of the bot or the token of the bot. Alexa skills as well. Like you can deploy multiple Alexa skills to the same API.

Okay, so the subpart of the deployment is really something. This is inside the expo.

Yeah, not all of them will have it.

Yeah, I understand that, but I mean, that's the URL dispatcher or the multiple endpoints or whatever else. So that does not have to be represented in the first or third argument. Right. Ok, so service type. Ok, the specific server. So is it obvious that we can't package together? Yeah, we were planning to package those together. Is that a correct statement?

The service type and the server? Yes, it's already, I mean, service connect is already in system and documented and well used.

So. And how does it, how does it package those together?

Well, service connect. When you connect to a service, then you, you get back service object that represents that.

All right. Okay, so, so this is packaged with service type.

As a matter of fact, you might even have two different connection to the same server with different permissions going on at the same time.

Yeah. Okay, so that's a service object. So now why is the deployment instance not in the service object?

Well, because you don't want to create a different service object when you have to deploy 15 API functions to the same instance of was you don't want to. You know, sometimes you have to rewrite one. So I think, at least for the first two, to me, it's kind of obvious that it's useful to have something that you can reuse to rewrite on top of something.

Okay. Okay, so deployment instance you're arguing should be the third argument of service deploy.

For.

Given the experience with cloud deploy for the first two, I have no doubt about that. For the others, maybe there's some discussion to be had, but.

Well, what do other people think about that? What is the location for each of these other things? Okay, so for these, the location is the cloud object. For a mail server, the location might be the email address. Am I making sense? Am I making sense?

I think yes. Yes.

Okay. For an Alexa skill, what is the deployment instance?

It's a URL or could be a cloud object. It's essentially a cloud object.

And what is it used for? It's used because. Okay, so for the Alexa skill, there's only one server, right? Right.

The actual server is sort of not part of what you care about. It's just Alexa.

But Todd, I am thinking, like, for the Alexa skill, like for the Telegram bot, you have at the same time like a pointer to the specific skill and the pointer to the cloud object. Right.

Well, at the moment you don't have a pointer to this specific scale because there's no way to. You don't programmatic do that from the Wolfram language. If we had a way to do that.

I'm not saying you do it from the Wolfram language, but once you created the whole scale, et cetera, doesn't the Amazon API give you like a token?

No, you. You give your URL to the, to the Amazon API, you say this is the address that you call when this gets.

But in theory, just like for the telecom bot, there could be like, maybe they have an API endpoint that says set webhook to this URL so that you don't have to copy paste that URL and go put it on the website.

Right.

They have a full programmatic API for setting up all aspects of your skill. So, yeah, you could supply the URL programmatically.

We got 10 more minutes for this meeting, so let's figure out what we're trying to achieve here. Okay?

Okay. Next up, ChatGPT doesn't really have a third argument as it is done right now with the limitation of the API.

Okay.

Like, it's one per server, so one per port.

Right. That's a very specific issue for right now.

Yeah.

And you could imagine that, you know, in a, in a world where I don't even know how this would work, I mean, right. There might be some world in which you have something like Wolfram Web Engine. That can deploy to different subdomains and things.

This isn't that horrifying.

Yeah, there are two versions there, actually. One of them, which is if you. I'm not sure if you can do that, but if you can squish everything to API function as well. And it's actually kind of nice. So. Yeah.

All right, fine. Okay, so what do we have to. What else do we have to figure out here? So service deploy, we think we understand how that works. A service deployment is the return value of service deploy. Correct.

But it could also be a third argument. Like, for example, was.

Yes, I understand. That is an overwrite that overwrites an existing.

Yeah, no, no, like, is that correct? Just.

I just want to be clear about that. That's what it does. It overwrites an existing deployment. Correct. Yeah, but synthesize a service deployment to specify where you want to put things. You would only get it back.

Oh, no, I. I disagree. If you look at the second last example of service deploy that I added.

This is in this file here.

Yes, yes, like was, which is the last example.

Include definition.

The last in the. In the main section. Okay, that one. So like was likes to have extra information other than it doesn't just have one location, has resource and endpoint and resource type and stuff like that. So sometimes you want to specify more things. Then you get an another service deployment out which contains that information, plus more once it's created it.

Okay, I'm totally confused. I'm totally confused. And you're saying that this is metadata that you want to be able to just give. This is wrong. You want to be able to give a naked expression here, unlike in this case where the expressions are deeply decorated. You see what I'm saying? You want an el cheapo. I want to give a raw expression here. I'm going to put all the details that here are in that payload expression. You want to put them in the service.

Yeah, but. Because those things are not the same. But those. Those things are like very specific things to how was was designed. And they just tell you where to lodge. That expression. Doesn't. They don't. They don't change the expression in any way. So if you like, you could. You could.

But that's the same thing here. View and organize files on a computer has nothing to do with changing the functionality, does it?

Well, it kind of does because it tells the. The. It tells the.

The.

The chat GPT.

What do these do? What do these things mean? What do these mean?

So, okay, so the resource. I don't know why they split this and it's not a single thing but the end point.

Why did we do this meeting without Andrew? If we're talking about.

Andrew was invited.

Well, where is he? Why did this meeting get started when we didn't have one of the people who are supposed to be.

His list is optional on the invite.

Look, I don't think Andrew has weighed in that he is fine with Carlos suggested changes and any other changes to service deploy. He's basically okay.

So I don't understand. Would somebody explain to me why are these things being put in this? You know, we got to have a consistent way to do this. Why are these being put here as opposed to being put in some kind of decorated association here?

Because I think that you're sending that expression to a location that is like. It's like, why is the permissions something that comes out of the cloud object, not of the payload?

You.

You of the first target deploy. It's the same thing. They're like, they. They want to be able to specify separately where they put resources and what the URL to reach them is, that then you have to specify what the.

URL to reach them is. I thought that's exactly what this is here. Endpoints are or whatever.

Yeah, but I, I don't know what. Why specifically they did the different thing.

We don't have the people in this meeting. We need the people in this meeting. If we're gonna. We're not gonna have a mystery meeting. But we're wondering why they did that.

Maybe they thought it was more flexible. But in general, you. You might have like, for example, for Telegram, it's the same thing. You have the, the API that. You have the Telegram API token and you have the Wolfram Cloud location. Those are two places you need to launch this thing in. And if we did the Alexa part programmatically, you would also have two places.

I understand it's calling a specific API in the cloud, right?

Yeah.

That's what you mean by it's a particular place. But that's exactly what's happening in the ChatGPT. Yeah, but when it's specifying an API.

Function here, when it says. When it says, this sets the web hook, that URL read of URL build etc contains a token in there. That thing is where you lodge it on Telegram APIs.

Yeah.

So you have two URLs that you have to.

Wait, wait a second, wait a second, wait a second. There's a big mess here, which we already have with mail receiver function. As we went through last time. But you seem to have forgotten. Okay. The problem is that if you, you know, for example, in one of these things, it's going to deploy a cloud, it's going to deploy this API function in the cloud, which means there's a cloud object associated with that, right?

Yeah.

Right. So there is an implicit. There are multiple things being deployed. In the case of mail receiver function, there's a, an API function being deployed in the cloud and there's also something being lodged on the mail server that represents the. That is the equivalent of webhook for the mail server, correct?

Yes.

Okay.

Do you agree that those two things are substantially different?

Which two things?

Payload. The cloud object and the email address are not the same thing as an API function or a mail receiver function. They're not Wolfram language code, they're metadata.

No, I don't agree. The API. No, I don't agree. The way that this is set up here, this will implicitly deploy a cloud function, a cloud, you know, a cloud object with an API function and then set up the appropriate web hook or whatever it is calling stuff to get to that API function. Same thing in these other cases. Exact same behavior. Right? It's the exact same thing. I don't think there's any difference at all. Am I missing something?

Yeah, I think that, you know, this, this chat GPT thing, once you point it to a server, it's deployed to that server and it is at the root of that server with all the stuff that you put in that association.

That's just a detail of how things are set up.

No, but it's not a detail. On the other there you can say, wait a second, I don't want like when I'm doing a service deployment of was, I want to take maybe like this file, put it in this resource, which is different from the resource I had before, but pointed to the same endpoint. And so those are all locations, they're not payloads. It's just that it's a two pronged location, just like for mail receiver function. Whereas the ChatGPT thing doesn't really have locations.

Why? It has locations. It's deploying cloud objects. That's a location.

Well, no, well, okay, hold on. Right now it's not because the main version right now is deploying quote unquote to local host.

Yeah, right, right.

If we have a version that deploys to the cloud, then. Well, it depends on how we address the sort of whole subdomain system in the cloud. Maybe those are just secretly cloud objects.

Right, Right.

Well, yes, but even Then it's a little complicated because. Well, let me see. I guess actually it is just one cloud object with a URL dispatcher in it. Probably.

Okay, yeah, but.

But still you would put in the third argument, you would have a subdomain, you would not have the prompt.

Sure.

Okay. Normally in a location here you would have the name of a cloud object or something like it, or a URL. Is that correct? But here you're saying there are multiple things you want to give you.

There might be. You know, the, the, the way I did is like you can put a string there. Going to synthesize the resource and just put it in and you just specify the endpoint.

I think it's a mistake to have that be. I think if you want to overwrite a service deployment, you put a service deployment there. If you want to create some kind of thing, I would just put an association there. So I'm saying, because it's not going to filled in a bunch of the elements to be a standalone service deployment, it better be the case that you can just, you know, given that service deployment, there should just be a way to call it. There's no guarantee that the service deployment you put there is a callable service deployment.

Fine, Fine by me. I can put an association.

Fine.

I don't. I'm not married to the. To having service deployment as the third argument.

Okay, fine, but notice there will be a service deployment as a third argument if you are overwriting an existing service deployment. Correct.

Okay.

But in the generic case, you might not specify everything needed to have a service deployment.

Yeah, sure.

You shouldn't call us a service deployment if it is an incomplete one. It should just be an association.

Okay.

Then the output should surely be a summary blob because it's often going to have multiple URLs and God knows what else. Am I making sense in this case? It should say service deployment or from application server. You know, it should be a multi decker summary blob which says the hierarchy of things, the server type, the server, you know, etc. Right. Okay. I think we have some kind of plan here. Everybody feel okay about this plan? Anybody object here?

No.

Okay, Todd, if there are further things that come up, you need to kind of crispen them up. And we're probably not going to have a chance to have another meeting about this, so please get the documentation. Sensible. Go. Listen to what we did last time. You came up with a reasonable sentence. I forget what it was. Make sense.

Hey.

Yep. Okay. Okay. Anything else anybody wants to raise in this meeting. We recovered it. We're not even over time. Disappointing that we even had to do a second meeting, but it is what it is. All right, let's not lose the place where these things are. Now, Aubrey, have you got what place these things are? Yep. Yep, I do. Okay, thanks, guys. And. Actually, Nick has commented on the live stream here. Deploy a local directory of list of files to make a simple FTP or HTTP service on a file server. That's what that would be another example of a target, wouldn't it be?

I mean, it is supported by both WAS and wwe. We don't have a simpler one.

Okay.

But, yeah, I mean, sure, could be done.

Okay.

Existing FTP. Yeah.

Okay, Good stuff. All right, thanks, guys. See you later.