Live CEOing Ep 702: Language Design Review of ServiceDeploy

Okay. Hi everyone. Another live stream. Today we are looking at another piece of Wolfram language design reviewing for version 13.3. I hope this is the Service Deploy framework. So the basic idea of Service Deploy is there is an external running service out there and we are going to lodge something with that service which is essentially a callback to our system. That a fair characterization, Carlo.

Not in the case of Wolfram Application Server, Wolfram web engine, in that case. It's launched there. And that thing, that external thing contains a Wolfram engine itself. So it doesn't need to talk to cloud or anything like that.

Okay, so it doesn't need a callback necessarily. So it's simply. So you're saying this is, by the way, absolutely crazy, that description there. What the heck does that mean?

Well, I. I kind of. I decided to mirror what it says for cloud deploy. So service deployment instead of cloud deploy. Cloud object. Sorry. So service deployment is the cloud object of service deploy. So.

I know, but. But with that wording it becomes kind of meaningless. I mean, I don't remember what cloud deploy says, but.

But that says deploys expert to an anonymous cloud object.

That's very different to an anonymous service deployment. I mean that. That's a. That's completely different because expert or service. Yeah, yeah.

Putting anonymous in their evidence.

Yeah, I know what the heck it means that it's anonymous. I mean, it's. It's like it's not a Twitter. The bird has been. The bird has been not necessarily deploying a Twitter bot, but I mean, I'm just. I'm thinking of the masked bird because it's anonymous and all that kind of thing. Never mind.

It's a dog. Now the bird's gone.

The bird is gone. Wow.

Yeah. Musk changed the logo to the dogecoin.

But that, that was a belated April fool, I think. Like April joke.

I thought that. I wondered about that. It seemed like.

Yeah, I don't think. I don't think, you know, Twitter is a bird and. Yeah, that's tough to. Tough to overcome that.

Well, they definitely changed name to Barker.

He was just pumping up the dogecoin price, probably for a weekend.

Yeah, yeah, right. The, um. Okay, so. Okay, so the example for Wolfram Application Server works. How does this have. As a. I mean, presumably in the documentation pages we'll do something like we do for. Service Connect and so on that, you know, because on the Service Connect page we have a list of actual services with all their different characteristics. Right.

Yeah. And. And was has a service page as well, which you See if you have the WAS packlet installed.

Well, you should see it anyway.

I mean, that's not the case right now, but I agree with you. And we are moving this stuff to, to the main documentation and not in the packlet.

Okay, but, but then. So for service deployment, the expectation is that there will be a list of supported external services and that those initially are. So, so what do you deploy to a. I'm so confused. What do you deploy to Wolfram Application Server? If you're deploying an API, for example, do you simply take is expert in that case API function?

Yes, yes. So the existing. The thing that I inherited from the was group required an association as a second argument where you were forced to specify where you would put the resource, what the endpoint was, etc. But we can do that like we do with cloud objects. We can also generate that stuff you don't want. If you don't want to specify it.

Okay, let me give you an example. Okay, well, I don't think that's quite as obvious as you think. Okay. Mail receiver function is something that should be a service deployment. Right now you can cloud deploy a mail receiver function, and that's just wrong. Okay, what does it run in the cloud?

When it gets triggered, it has a.

Callback to the cloud, what it runs. Look, if you use mail receiver function, what it fundamentally has to tell you is this is the email address you've been. You've been assigned. Okay, it's got to tell you two things. It's. It's a total hack. What? Oh, there we go.

But doesn't it have to have a function that, that gets run when the, when email is received and that function needs to run in a cloud question mark.

Yeah, it runs in the cloud, but. But it is triggered by something that comes from the mail, a mail server. That's the point. So what's happening here? This is a total hacker Lola. I mean, this is a cloud object, right? With its own uuid. But it also, so that you know what the heck to do, it gives you this weird mail toothpaste in here because it's really got to return two.

Things that should be a service deployment.

Yes, I know, that's what I'm saying. Right? So because it's got to return two things, it's got to return. Where did it lodge? Because there are two anonymous things it's creating. One is the cloud object and the other is the hook into the mail server. You see what I'm saying?

Yeah, yeah. And yeah, when. I mean, while that's not necessarily for was when we get to chatbots, etc. I will show you what I think that should be.

Ok, so but I mean, by the.

Way, just in general though, should is service deploy of. Is that like, can you service deploy to Wolfram Cloud and is that equivalent to cloud deployment?

I think it should be.

Now you can't, but I don't see why. I mean, I can implement that in one line probably.

So.

Yes. Right.

Yeah.

So I guess then that makes sense because then you could. But now there's a little bit of weirdness with mail receiver function though, because then presumably you could service deploy to. You could service deploy a mail receiver function to the cloud, but then you'd get back a service deployment object as opposed to a cloud object.

No, you shouldn't be able to do that. You shouldn't be able to do that. The service deploy to service deploy it to some mail to a mail server. Right. To something which is a, you know, an anchor point for a mail server. I'm not quite sure what that looks like. I mean, you know, the anchor point.

If you want to do what if.

You want to do.

It's done with the cloud right now where the cloud is the anchor point for the mail server, presumably what you give it is some sort of cloud representation.

Sure. Of a mail server.

Yeah. Maybe you have some mail server wrapper around it that makes it unambiguous that this is the cloud as a mail server as opposed to just the cloud.

Right.

There's one thing I'm confused about here is like, I don't know how it's implemented, but could you technically tell the cloud. Listen to this POP or IMAP server, which is not@wolframcloud.com but it's at something else. Here are my credentials. Well then it has to be the cloud. Both ways, right? Both word.

Right now, yes, the server is a. Look, this is a mail server that sits next to the cloud. Okay. It's not. It's a mail server that has a relationship to the cloud and that has. I don't know exactly how it works here. Let's see. Mail response function, supply to respond to the sender. Okay. That's something different. Okay, So I mean, we'd have to ask somebody how this exact exactly implemented. But fundamentally it's a mail server that sits in parallel to the cloud. And what happens is the mail server runs. What is it Proc. Mail RC or something? I don't know exactly what it is, but the mail. What's happening is the mail server is Calling the API in the cloud. See what I'm saying? And this is my belief that you could set up any old mail server to do that.

Maybe, I don't know, but not many people have. I, I wonder if you could do that as, rather than as a mail server, as a mail client. So you, you, you give our cloud our mail function, the password to your email. We, we check your emails and when something comes in, we do something.

Okay, that's a completely different thing. That's the Mail Server Connect functionality. And I don't believe that we have a notifier mechanism, but one can imagine that. Okay, that works with. That's a whole different thing. But anyway, I think, okay, that's Mail Server Connect. Okay, that's a thing for connecting to an IMAP server, for example. I forget what kinds of servers are supported. Okay. And then you can read your mail. Get what I'm saying? Anyway, I think it's pretty clear what we're doing here. The main point is that in the case of mail receiver function, the main, main thing. What the heck is this? Cloud get a mail log. Oh, I see, I see. Cloud put to mail log. Okay, I get it. Right. The, the main thing here is the deployment needs to return two things. The name of the cloud object, which is the proxy for the deployment, and the actual mail address. And the reason it needs the cloud object is because if you're going to delete this deployment, you need to know where the deployment is. Do you see what I'm saying?

Yeah. And if you open up the service deployment documentation page. The idea is deployment. The idea is that it contains an association and depending on what the type of it is, the name of it is, then it. I don't know if that link will work because maybe it still links to the pattern. So like right now I specified what it does for a Wolfram application server. Wolfram engine. Maybe name is not the right key for that, but we could have like this be different for all things and this displayed differently for all things.

Well, why don't we just call it service?

We could call it service. Yeah. The problem is that as it's implemented right now, service was what is URL now? Which is honestly kind of weird.

That seems wrong.

Yeah.

What do you mean? The URL for the deployment, that's a URL. No, you shouldn't say that. You should say a URI of some kind of.

Well, in this case it is a URL.

I know, but it might not be.

No, but for that says for wallflow application server, then in that Case it's the URL.

Okay, fine, but that should be on a separate page, like for the service execute for the service connections. Right, the service connections list. You know, Twitter is a separate thing from, you know, archive is a separate thing from pdb, et cetera, et cetera, et cetera. That same thing should be true here, of which the thing should be service. And then within that service, there is an identifier for this particular deployment. Correct?

Okay, yeah. So, yeah, separate pages, like for interpreter, for example.

Yeah, right. But I think that should be at least uri, if not just identifier or some such other thing.

Get what I'm saying?

Yeah, but I. I mean, my idea in putting URL there is that was that I don't want to shoehorn the names for completely different services into like, you know, you deploy.

Okay, so for mail receiver function, what should that be? The service is.

Services can be mail receiver function. Then you get.

No, no, no, it's not mail receiver function. Mail receiver function is a different thing. Mail receiver fun is what you are deploying there.

Right?

So that's service is what, Mail server or something? Wolfram. I mean, it probably is Wolfram Cloud Mail Server. Yeah, that's probably the service.

I'm not sure because, like, it is specific to a mail receiver. Like, you can't you, you. You're. When you service connect to the Wolfram Cloud mail server, you can't just read the mail, so.

I know, I know, I know.

Which I would expect for something that is called mail server.

But you're not service connecting, you're service deploying to it.

Yeah, but first, before I can service deploy, I usually service connect. Like all things that work in service deploy work in service connect. Maybe it's useless to service connect to it because it's like open or whatever.

But. Well, okay, that's interesting. But I mean, you understand what I'm saying?

Yeah, I do, I do. But what I'm saying is that it's very specific. It's not just mail server, it's mail server for doing this kind of mail receiver stuff.

So maybe whatever. Mail Server, Wolfram Cloud, you know, mail receiver Server would be the full name, I suppose.

Yeah.

Of the service.

Mm.

Actually, is it a service? Because it is a server. Maybe that should be. No, it's server type is what it really is. Is that correct? Because it may be. If it's WM Application Server, then you might have 10 of them.

Yes, you might.

So I think there's yet different things. There's a service type, then there's a particular instance of that service type. And then there's the particular deployment that you have out of potentially many deployments that are hanging off that service of that instance of that service. So I don't understand the relationship between that and endpoint.

Endpoint in the case. So endpoint is like URL without the base. In this case, for was. So it's like where you need to go relative to the server.

I don't think if you scroll down.

And look at the last example, you will see what the endpoint is. It's usually like just hello in this case.

I think this is very obscure.

You're right. I just inherited it.

Well, was this Andrew's design or whose design was this?

Yeah, I guess Andrew. And then it was implanted by Dylan.

Okay.

So I'm trying to bring it back to look more like. Like cloud deploy. I think cloud deploy is nice. Easy, simple.

Sure. Yeah. Well, so we need to. Then. Look, I think your point is don't standardize the names because it's hopeless and therefore the names should be as useful, so to speak, as possible. You know, so. So in here. Let's pick a random one here. Why is this so slow? What's. What's going on here? This is. Again, don't understand what's going on. Okay. Requests. These are not associations. This is a request type.

Yeah, this is.

So this parameters. What the heck is that? That's an option, not a parameter.

That's. That's indeed strange.

Seems.

Are you sure? No, I'm not sure. Those are options. I think that's service. When you call service execute, you always give it a connection and then an association.

Yeah, yeah, that's the third argument. But why is that not in a string if it's key to an association? It's really strange.

Yeah.

Yeah.

Okay. All right, let's take a look over here. All right. What do you have here? So you have. This is a telegram bot or something?

Yeah, so I made a telegram bot. If you scroll up just to see what it would look like. And the thing is that there is already a packlet that does telegram bots that's been done by. By this guy Kirill Bellov, which is a YouTube.

Okay.

It's. It's pretty nice, but it's like, it's. It's very specific to telegram.

Okay, so. But hold on. When you say service deploy, it's not a telegram bot. You're deploying. You're deploying to telegram, right?

I am. So there is. The problem with telegram bots is that if you want to create one, you need to do it through like you have to take. Talk to the bot father and you say new bot. And then they'll give you back token for that bot. And then with that token you can set you, you have to set stuff on their API by saying set webhook and you point that to any URL.

That's fine, but I'm saying the name here should be service deployed to Telegram, not to Telegram. Bottom.

What if in. Okay, Telegram supports different things? In this case, this is a bot. But there, there's like games which haven't even looked into which have a different API. And so, you know, maybe you want to add.

Well then, then let's call it something like Telegram bot API. Or you know, we should also Telegram bot.

I mean it is, it's not just Telegram, it's the bot part of tele. What Telegram can do.

I understand that, but if you say service deploy Telegram bot. I don't know, it's, it's, you know, what is it? It's deploying to the Telegram bot service.

It's doing two things. It's. It's deploying to the Telegram bot API and it's deploying an API to the cloud. In this case, you could deploy.

I got it. I understand. That's what's going to all of these. So what it's doing with mail receiver function as well, it's deploying an API to the cloud and it's deploying something to the mail.

Yeah, it's not all it's doing because again, if you were deploying to a Wolfram Web Engine instance or Wolfram application Server instance, nothing is going to the cloud. And for example, you might want to do something where, for example, you're deploying a Telegram bot, but where the API calls is on wwe, for example.

Or for example, there's one of the things that the packlet in the packlet repo does is to set it up just like you did Christopher for ChatGPT as, as a socket, as a local task, whatever. So you, you, you can even do that if you want.

Sorry, sorry, I, I spaced out for a second here. Could you.

But basically just that you don't always. The cloud is not always involved because for example, you might deploy either there might be no API to deploy or the API might be deployed to something like wwe or it might be a locally deployed thing on like local host.

Yes, but it's still Wolfram engine running somewhere, whether it's the cloud or whether.

Right.

Well, wwe, we can think of it.

In the same way, it means either way. I mean, one, it means you need to have some way to specify to which thing you want to deploy that part. Or do you need to be able to first deploy that part, get some API and then feed that into this other service?

Right. Okay, let's take a look at this. So what does this actually look like? What is this? I don't understand this. What's this? What's that?

Look at the shorthand version of this. So in general, the structure is okay if you ignore the first argument. The second and third argument are like the first and second of cloud object. You either have a shorthand that can be a string or you have a full fledged cloud object or service deployment in this case.

Okay, but that final thing is kind of like this is the. Okay, look, look, let's go through this again. There's a service type.

Or service object in case you have to connect, which is not the case here.

Okay, but hold on, hold on. There's a service type. There's an instance of the service. Yeah, okay. I mean, like you could have multiple, you know, chatbots that are all of the same type. They're all llamas or something. They're all, they're all aardvarks, whatever it is, but they're different ones. Okay, so the first thing you have to say is what type, which one? What are you deploying and where are you deploying it? Within that instance of that service type.

Yeah.

In the case of Telegram, telegram is monolithic, so you can have multiple.

I understand, I understand. There's no private telegram, just one telegram. Right. But in other cases like Wolfram Web Engine, there may be many instances.

Yes, absolutely.

Okay, so I don't know whether we've had to address that in the service connections business of multiple instances of the same service type. Have we.

If you, if you need to connect to a specific instance, you do that with service connect some way and then take the service object that you get from that and pass that as the first argument.

So you're saying in, in the multi instance case, which includes Wolfram Web Engine and Wolfram Application Server, you have to do a service connect first, not. Yes, yes, yes, because otherwise you don't know where you're going. Unless there's, unless you have a, you know, dollar cloud based type thing, which you could have. Get what I'm saying? That's the point of the system services function, is to allow you to specify system services, allows you to specify what services. What am I saying? What, what services? You, You know, which instance of a geoserver you're going to use, and so on. So that's a way that you could specify, you know, if you just want to say Wolfram Application Server, then System Services could let you specify which one.

Yeah.

Do you get what I'm saying?

Yeah, that's true.

Okay, so. So the, the. The multi instance thing would generally be a service connection. Unless you have specified it.

Service object school.

Right, right. Unless you. Unless you specified it. And this is very similar to external evaluate. Right. That you have to have. If you've specified what, you know, instance of, I don't know, SQL or something you're using, then you can just say External evaluate SQL. But otherwise you need to give it a. An external session object. Right. Am I correct?

Mo mostly. Yeah, that's. That's the. I think the analogy is good there. You either give it a string and the system looks up some particular instance. Oh, that this is the pipeline in the Registry. In the Registry, or you create a session somehow.

Okay. And the analog of the registry here is System Services, I think. Do you agree?

Yes, I agree that that would be the place to store that. You know, which. What I mean when I say welcome Application Server.

Right.

Particular environment.

The first argument is the service, which is either a service object or. Or a string, which is resolved by the registry. Second argument, what you're deploying. Third argument where you're deploying it. That's similar to cloud deploy. Right? Wait, Gus.

Yeah, yeah. And if possible, the third argument can be omitted or can be made into a shorthand, or it can be as complicated as you wish, depending. Right.

But one important point is when the. There are two things. See, this is where it gets screwy because. Okay, what, what does service deploy return? It returns service deployment. Is that correct?

Yeah, not necessarily the same as was given because it can end.

There's no given. There's no service deployment given. There should not be any service deployment that is given.

Why not?

Because it's totally confusing.

But Cloud object can take a cloud object, as Cloud deploy can take a loud object. If you want to redefine.

Okay, okay. If you want to overwrite it. If you want to overwrite it.

Not only. It's also useful because you can add metadata to that. You know, it's not like you can't.

Give it a UUID one. You can't make up a UUID and put it there. You may not be able to group a uuid.

Steven. Cloud object open close creates a uuid.

I know.

That doesn't really exist on the server yet.

Yeah, I get it. Yeah, okay, but, but in this case here, the, the third argument, if omitted, needs. It needs to tell you where it put the thing because you don't know it's some uuid.

That's why it returns the service deployment.

Fine. Which contains both where the server is and where the particular service within that server is.

Exactly. Actually, by the way, this would be much simpler in the documentation service deployed, there are examples that do actually work now rather than this, you know, Telegram bot thing, which is kind of a toy still, so.

Well, first, it's this case that works now, right?

All of them work now.

Yeah. Okay, but I mean, that's a service object. Service deploy. I don't like this. This doesn't seem right.

Maybe it's right, but the one above where it's just a string, it's much simpler and easier. I don't know why the design of was wants you to specify the resource explicitly, even if it's like. In the end it's not exposed. So you could store all the resources as whatever, as. As UUIDs, because you never see them.

Right.

I don't know whether there is this distinction. And in fact, in Wolfram Web Engine, there isn't.

Okay, okay, okay, hold on. The. All right, let's come back. I mean, there's some cleanup then for application server for its specification, but let's look at some of these other ones and we're going to run out of time. So here. Service deploy to Alexa. What the heck is all this stuff? No, you.

This is. This is. We were just brainstorming about what service deploy would look like if applied to my Alexa packlet.

Okay, but remember, the second argument is what you are deploying.

Right, Right, but this in effect is what you're deploying because you don't. The. The. The Alexa code. Alexa paclit code builds the API function for you from this specification, which is a list of handlers. So in effect, this is what you are deploying. It's just a, it's just a very simple way to specify without actually having to write an API function, that API function gets created for you.

That, that. I mean, that's also why that's under the header curated, like for Alexa. If you were to write every time the API function on your own, you'd have a lot of boilerplate and we take like, what's the value added on?

No, I understand that, but. I understand, but. So what you're saying is this is a case in which, whereas with the Telegram bot or mail receiver function, as soon as you go to that mail endpoint, it is hooking back, it is calling into the cloud with a particular API function. The case that we have here is something much closer to our URL. What's it called? URL bundle. What the heck is that thing called?

URL dispatcher? Not quite. Because the intents then will have all sorts of keywords that you have to set up on the Alexa side first.

But yeah, no but I mean, but the point is it's a multi headed. There may be multiple API functions.

No, no, there's just one API function that acts, but it has its own dispatching logic to these different intents. There's just one endpoint in the cloud for handling this skill. This just is just a very concise way of letting you specify the minimum amount of information, you know which intent gets, which gets handle it, which function. And what happens is a large pages long API function effectively is written for you that handles all sorts.

But basically let me just give the hierarchy again. Okay, the hierarchy is service type. I wish this was in Dropbox. But anyway, service type, service instance, service service service server basically then deployment instance and then subpart of deployment. Is that correct?

It is correct. But not all of the services will have all of these parts.

Right, I know that, I know that. I'm trying to understand what is the hierarchy here.

Oh, that's, that's correct.

Okay, so in other words, this is effectively a bundle of APIs. That's what that's doing. The subpart is labeling the different parts of a bundle of APIs.

Yeah, pretty much.

Okay. And the deployment instance. Okay, so I, I'm going to claim that we really shouldn't have it looking like this. That what we should do is service deploy should have as a convention that it can have an association as its second argument where the right hand side of the association is always API functions.

Well, what would I put here? I don't want to put an API function here.

What do you want to put? What is that function? What is this function?

That function is a function that handles one specific request, one specific utterance that you might make.

So it's a function, you're just giving the actual raw code that runs. Given that utterance.

Exactly.

Does it have an argument or does it just run?

Yes, it gets arguments as slot values from. Yeah, it has arguments. The, the, the arguments are determined by how you set this skill up in the Alexa portal.

Okay, so what we're saying is that every service has a harness and it's going to take the Second argument. And when the service is, is called, it's going to take the second argument, apply the harness. I'm not sure the harness is the right term here. And then call it.

In other words, that's not really right because the harness, if you're thinking about the harness as being something that runs on the Alexa side, that harness is, is at the moment has to be specified manually on the Alexa site. But that harness goes in the third argument in the service deployment.

Business.

Business. This is literally the API function. This is just, just think of this as another way to specify an API function, except without having to specify the details of the API function itself.

I think another helpful way of seeing this is like if you, if you put an API function in the second argument for, for cloud deploy. Sorry, in the first argument for cloud deploy, it can modify the literal code that is in there, picking up definitions and stuff like that. This is a more complex transformation of that code.

Yeah, you can think of it which.

Is context dependent and so on and so forth. But for, it's not always necessarily an API function because for example, the telegram bots have a JSON payload in the body, so they don't have parameters per se, you have to parse.

Yeah. Or another one is if you go to the ChatGPT plugins, you don't give an API. The endpoints take many parameters, more than an API function because they need prompt information.

Well, maybe I shouldn't have written it as API functions, but.

Okay, well maybe there are enough options to API functions that you can pretend. But yeah, like you can hide it in the appearance rules or something.

But yeah, okay, but that's exactly the thing we got into with mailreceiver function, where you're hiding things in metadata and it's a mess. So let's look at this case. Is this real, this Service deploy of ChatGPT?

No, no, it's not.

It's not. Just trying to imagine how the thing that Chris wrote would look like in this brave new world where we split like the metadata, such as prompt description and so on from the actual functions.

Okay, so these are the end points which are referred to in the prompt, basically, and they're API functions in this case.

Well, yeah, so the top example is the real one, although it's a little ugly looking because it uses packlet symbols. But yeah, but the right. So you can see that there's, there's, you know, each, each function needs a name which I guess is encoded with this association here. It can also optionally take a prompt that's associated with each function. So you could say, you know, this is the get to dos. Then you could have a prompt that says use this function when you want to get the list of to dos. You know, and then there's also, there's also prompting for each argument which you can encode with the help parameter and API function. Yeah, yeah.

Okay.

We're not going to get this solved, this incident. We're going to have to continue this because I have to go to something different in a moment here.

But Stephen, can we just back up to the overall. We're just trying to get your approval on a change to the argument sequence of service deploy to make it more generalized. And the point of this was just demonstrate multiple cases how they're different from each other. That in fact, Carlos proposed argument sequence makes sense.

So the argument sequences what service you're putting it at, what service instance you're putting it into. First argument.

Yeah.

Second argument, what thing you're lodging there?

Yeah, that's the Wolfram language. It's the Wolfram language thing that runs. Right? Not, not the thing that's being lodged in there. This is typically being lodged in the cloud or in Wolfram.

No, it's not being lodged in the cloud. It's got, as you pointed out your Alexa skill and so on that you are.

That entirely runs on the Wolfram cloud side.

No, I get it, but I'm going to point out there's a little bit of a problem here. Okay, Remember this hierarchy service type service and you know, service server and then sort of sub case within that server. Like you are, you know, like a cloud object on the cloud. Right. On a particular cloud. Okay, the third argument that you have is the description of the sort of, of the particular deployment, like the particular cloud object, the particular mail, you know, mail address, those kinds of things. Am I making sense?

No. Yeah, I think that. Is that right, Carl? It's the third argument.

The third argument is Argument. The third argument is the best specific.

Location within the particular service.

Right? That's information about the service. The second argument is information about what happens on the Wolfram language side.

I know, but I'm pointing out your first and third arguments are both information about the service, which is different from cloud deploy because cloud deploy takes a cloud based option. That is the analog of your first argument here. True.

That is true. But on the other hand, I think that it's. It also follows like the third argument in many cases can be completely omitted.

I guess it, I, I get it, but I'm, I'm Making it back to the first what? Well, no, I'm saying, I'm saying that you could, you could combine the third argument into the first argument because I think that border is. Is fuzzy. You know, what's on a different instance of the application server versus what's a particular endpoint within that?

Can you look at the first use example under service deploy in the second notebook you have there? No, on the other notebook, the documentation notebook. Like this thing where you do service deploy, the was service connect object and then just API function is somewhere like.

Yeah, that's good, that's good. But I mean, you can do that. The, you know, you can do that anyway, if, if the first. The anonymous case is easy to deal with, the case that is not so easy, which I claim should be put into the first argument, not split across. First and third argument is the specific destination within the server, right? If the specific destination within the server is automatic, that means create your own place uuid up your own place to get what I'm saying.

Yeah, but I don't understand, like, in most cases, the first argument, like contains the connection, the login and password stuff. You cannot deal without it, right?

Yeah, so.

So it, it is really. And also like service deploy.

Well, then I think you should have an optional second argument because I think it's wrong to split between the first and third argument. The, you know, you've got the server. That's the first argument, the server and authentication to get to the server. Another argument is on that server. Where is. Which pigeonhole are you putting this in? See what I'm saying? Which.

Yeah, but I'm not, I'm not that convinced because I think most cases like the, the service connection is something you put in a variable. It's very short in theory.

Did you listen to what I said? I'm saying the service connection first argument, the service object, okay, that specifies the server, how you get to it, it's authentication, all those kinds of things. The second thing you need to specify is which pigeonhole you are using on the server. By pigeonhole I mean the cloud object name, the mail, you know, the mail id, the skill name, you know, I don't know what it is.

Yeah, I get it. But what I'm saying is that if you do that, and the main case I wanted to cater to is someone who has written their first app on the cloud with cloud deploy and then they would just want to go and search and replace in the code cloud deploy with service deploy of WWE comma and that just keeps working because it's the same argument structure and they get the same app.

I'm not necessarily. Okay, so you're saying you're proposing the first argument is the server, the second argument is the thing you're deploying, and the third argument is the pigeonhole.

Actually, ideally what I would. What I really like is service deployment being service deploy, open, close the server. And then the other arguments like it's, it's like you can replace service deploy of WWE and, and cloud deploy.

Like, you know, I think that's a little weird.

Yeah, I know, but.

But okay. Comments from other people. So I mean the main point is, remember we three things, Server, payload, pigeonhole. Makes sense. Does everybody agree that those are the three things we're dealing with here?

Yeah.

And do we all agree also that pigeonhole in many cases can be automatic and so omit.

Absolutely. Pigeonhole can be omitted and the pigeon will find its own home, but the payload never.

So having them as swapping them from what they are here is weird to me.

Yeah, well, fair enough. I'm just a little concerned that the first and third arguments are going to have things that are very shared. And I don't like the fact that the service deployment could go in the third argument. I think that's totally weird because a service deployment is going to contain a service object.

I think that in 99% of the cases you're going to have, you're going to just refer to. And I don't know how well it works this right now, but if you have, if you are connected to one Wolfram application server, then probably you don't need to repeat.

Let me make a suggestion, Let me make a suggestion. If the third argument, if you have a full service deployment, you simply put it in the first argument and it contains the pigeonhole as well. You get what I'm saying? Don't put. In other words, you could either have a service deployment that has everything, the server and the pigeonhole. Right. Just not the payload, in which case you put that in the first argument. If you are separately specifying the server and the pigeonhole, you can put those in the respectively the first and third arguments.

Well, another version would say that the pigeonhole should go in the thing that you're deploying because at some level, sometimes it's, it's like, you know, the idea that there is a pigeonhole at all is a little bit vague.

Well, okay, so you might argue option to the service. Right? But then the argument that you're giving there is maybe you're deploying multiple things at a Time that go in different pigeonholes and how do you deal with that?

But like, I'll give you an example, right? So suppose you're deploying something, you know, like to AWS lambda.

Right.

So I mean, you're deploying something that's like an API function, you know, but. But maybe it has a name associated with it. Does that mean that the pigeonhole is, say the name of the, you know, of the path you should go to call the API? Or is that path just an argument to the deployment?

No, it's. I think it's an argument because the, the point is that if you keep the name but change the payload, you want to be able to overwrite it. That's what you do with Cloud Object, for example, like when I really need to go.

But the. You guys can continue if you want. But. But I really need to go and.

Well, do we need to.

We probably need to continue this one.

Yeah, we're seeking a resolution on this. Just.

We're getting close. We've defined it pretty well what the issue is. Let's. Let's see if we can just make sure we can distinguish between server and pigeonhole and how that works. Server pigeonhole and payload.

Right. And you didn't like the idea that the server and the pigeonhole are separated as first and third arguments.

I'm concerned that that's not going to work. And Christopher is pointing out that the payload is also mixed with the pigeonhole.

That. That's the. I don't know. I think that like we are sacrifice like 95% of the cases you're connected to one thing at a time and you don't care about changing the server that much. You just care about whether you're.

Well, that's what we did. That's what we did for cloud objects. Right? For cloud objects, we have a service, you know, a cloud base. We could have a service base too.

Yeah, but. And I think that it kind of works automatically if you're connected to only one Wolfram Application server. You can just take Wolfram Application Server as the first argument. Just the type.

Yeah, well, maybe, maybe. But I mean, but. But clearly you can't get away without the first argument. Just like for external evaluate. Because you need to say what kind of a thing is it? You know what? So I think this requires a little bit more thought and I need to go. So I'm going to. Okay. Okay. Bye.

Bye, everyone.

Sam sa.