A few questions on Stunt's package management (amongst other things)
5 views
Skip to first unread message
d. kajsh
May 20, 2012, 8:52:59 PM5/20/12
to MOO-...@googlegroups.com
I played around with Stunt for a few days and have some questions
regarding the package management.
It solves the problem of decoupling the objects from the database and
I think it does a pretty good job at it.
But what about updates and modifications?
Say, I start a new MOO today and get the Stunt.db with kernel 1.0.7
and lambdacore 0.0.4. How would I upgrade either of these packages on
the server when a new version gets released?
Packages like LambdaCore aren't going to be static, the objects won't
remain untouched after install. I will have to change and tweak code
all over the place when implementing new features. How can i share
these modifications with other MOOs based on Stunt+LambdaCore?
At the moment it looks to me like we're still left with packages where
modifications can't be easily merged between different cores. Would
splitting up/modularizing the LambdaCore help? That's probably not
feasible, seeing how tightly coupled everything in there is. Or maybe
a way to create packages that work more like patch/diff that modify
existing packages and which are easier to apply/revert?
I have several older MOO cores lying around which are based on
different versions of LambdaCore and I want to merge some of these
changes and add new features into a new MOO in a modular, shareable
way. Stunt looks like the way to go here, but I'm not sure how.
So how could that be solved? Or am I missing something here and
there's already a solution in Stunt?
Alright, now some other ramblings/bug reports:
* How do I compare different versions of Stunt packages or databases
anyway?
I wanted to compare the Stunt LambdaCore package to the original
LambdaCore database. First, I tried (and failed at) hoisting
LambdaCore into a package myself. Comparing the databases was equally
unsuccessful because of the different order of the objects. I ended up
@dump-ing all LambdaCore objects from both databases and then diffing
the results, ignoring all object numbers.
Comparing two versions of the LambdaCore package was also quite
frustrating. All diff utils for json choked on the size of the data. I
went on to install each version of the package in different databases,
compared them with compare-cores and still had lots of noise when
object numbers were different.
* Using $composed:import_package_from_file() directly to import the
LambdaCore package fails ("ran out of seconds"). Maybe importing from
local json files could be integrated into $composed:@install?
* What happened to $composed:audit() that's mentioned in the "Hoisting
Lambdacore" article?
* The interactive command line on http://stunt.io:8888/ doesn't seem
to work with Chromium.
Keep up the great work,
Daniel
regarding the package management.
It solves the problem of decoupling the objects from the database and
I think it does a pretty good job at it.
But what about updates and modifications?
Say, I start a new MOO today and get the Stunt.db with kernel 1.0.7
and lambdacore 0.0.4. How would I upgrade either of these packages on
the server when a new version gets released?
Packages like LambdaCore aren't going to be static, the objects won't
remain untouched after install. I will have to change and tweak code
all over the place when implementing new features. How can i share
these modifications with other MOOs based on Stunt+LambdaCore?
At the moment it looks to me like we're still left with packages where
modifications can't be easily merged between different cores. Would
splitting up/modularizing the LambdaCore help? That's probably not
feasible, seeing how tightly coupled everything in there is. Or maybe
a way to create packages that work more like patch/diff that modify
existing packages and which are easier to apply/revert?
I have several older MOO cores lying around which are based on
different versions of LambdaCore and I want to merge some of these
changes and add new features into a new MOO in a modular, shareable
way. Stunt looks like the way to go here, but I'm not sure how.
So how could that be solved? Or am I missing something here and
there's already a solution in Stunt?
Alright, now some other ramblings/bug reports:
* How do I compare different versions of Stunt packages or databases
anyway?
I wanted to compare the Stunt LambdaCore package to the original
LambdaCore database. First, I tried (and failed at) hoisting
LambdaCore into a package myself. Comparing the databases was equally
unsuccessful because of the different order of the objects. I ended up
@dump-ing all LambdaCore objects from both databases and then diffing
the results, ignoring all object numbers.
Comparing two versions of the LambdaCore package was also quite
frustrating. All diff utils for json choked on the size of the data. I
went on to install each version of the package in different databases,
compared them with compare-cores and still had lots of noise when
object numbers were different.
* Using $composed:import_package_from_file() directly to import the
LambdaCore package fails ("ran out of seconds"). Maybe importing from
local json files could be integrated into $composed:@install?
* What happened to $composed:audit() that's mentioned in the "Hoisting
Lambdacore" article?
* The interactive command line on http://stunt.io:8888/ doesn't seem
to work with Chromium.
Keep up the great work,
Daniel
Todd Sundsted
May 20, 2012, 10:48:49 PM5/20/12
to MOO Talk
Daniel, thanks for your feedback!
On May 20, 8:52 pm, "d. kajsh" <hsja...@hotmail.com> wrote:
> But what about updates and modifications?
I don't have a great solution for updates, yet.
> Say, I start a new MOO today and get the Stunt.db with kernel 1.0.7
> and lambdacore 0.0.4. How would I upgrade either of these packages on
> the server when a new version gets released?
I keep all of my application code in packages. When I need to
upgrade, I export my application packages and build a new core with
the latest library packages. Then I import my application packages.
In the near future I'd like to be able to upgrade packages in place,
but I'll need to do some work on the server, first.
> Packages like LambdaCore aren't going to be static, the objects won't
> remain untouched after install. I will have to change and tweak code
> all over the place when implementing new features. How can i share
> these modifications with other MOOs based on Stunt+LambdaCore?
My assumption is that packages will be static and changes made
directly to package objects will not be preserved when a package is
upgraded. There is no provision for extracting (or preserving)
changes made directly to a package (in a diff, for example) short of
exporting the entire package. If you're tweaking a package like
LambdaCore itself, you'll need to distributes your tweaks as part of a
release of the entire package.
The problem is that legacy cores like LambdaCore weren't designed to
be modular, and my packaging solution doesn't overcome that. Can you
implement your changes as/to children of the objects in the LambdaCore
package, and distribute a lambdacore_extensions package?
> At the moment it looks to me like we're still left with packages where
> modifications can't be easily merged between different cores. Would
> splitting up/modularizing the LambdaCore help?
It sounds like what you want to do is to make and distribute the
changes to a package. My vision was that the package itself is the
unit of distribution.
> I have several older MOO cores lying around which are based on
> different versions of LambdaCore and I want to merge some of these
> changes and add new features into a new MOO in a modular, shareable
> way.
Nothing that I've created will help pluck arbitrary code/objects out
of a database, unless that code is segregated out as a package,
independent of the rest of the core, with dependencies called out,
etc. etc. etc.
> * Using $composed:import_package_from_file() directly to import the
> LambdaCore package fails ("ran out of seconds"). Maybe importing from
> local json files could be integrated into $composed:@install?
A local disk cache of packages is on my todo list. I just have to get
to my todo list! I will look at the seconds issue.
> * What happened to $composed:audit() that's mentioned in the "Hoisting
> Lambdacore" article?
I removed audit() because it wasn't ready for prime time. It will
make it's appearance in a separate package.
> * The interactive command line onhttp://stunt.io:8888/doesn't seem
> to work with Chromium.
What version of Chromium are you using?
> Keep up the great work,
Thanks! Package support is far from perfect, and the process of
_making_ a package isn't particularly easy. I appreciate your giving
it a try.
Todd
On May 20, 8:52 pm, "d. kajsh" <hsja...@hotmail.com> wrote:
> But what about updates and modifications?
> Say, I start a new MOO today and get the Stunt.db with kernel 1.0.7
> and lambdacore 0.0.4. How would I upgrade either of these packages on
> the server when a new version gets released?
upgrade, I export my application packages and build a new core with
the latest library packages. Then I import my application packages.
In the near future I'd like to be able to upgrade packages in place,
but I'll need to do some work on the server, first.
> Packages like LambdaCore aren't going to be static, the objects won't
> remain untouched after install. I will have to change and tweak code
> all over the place when implementing new features. How can i share
> these modifications with other MOOs based on Stunt+LambdaCore?
directly to package objects will not be preserved when a package is
upgraded. There is no provision for extracting (or preserving)
changes made directly to a package (in a diff, for example) short of
exporting the entire package. If you're tweaking a package like
LambdaCore itself, you'll need to distributes your tweaks as part of a
release of the entire package.
The problem is that legacy cores like LambdaCore weren't designed to
be modular, and my packaging solution doesn't overcome that. Can you
implement your changes as/to children of the objects in the LambdaCore
package, and distribute a lambdacore_extensions package?
> At the moment it looks to me like we're still left with packages where
> modifications can't be easily merged between different cores. Would
> splitting up/modularizing the LambdaCore help?
changes to a package. My vision was that the package itself is the
unit of distribution.
> I have several older MOO cores lying around which are based on
> different versions of LambdaCore and I want to merge some of these
> changes and add new features into a new MOO in a modular, shareable
> way.
of a database, unless that code is segregated out as a package,
independent of the rest of the core, with dependencies called out,
etc. etc. etc.
> * Using $composed:import_package_from_file() directly to import the
> LambdaCore package fails ("ran out of seconds"). Maybe importing from
> local json files could be integrated into $composed:@install?
to my todo list! I will look at the seconds issue.
> * What happened to $composed:audit() that's mentioned in the "Hoisting
> Lambdacore" article?
make it's appearance in a separate package.
> * The interactive command line onhttp://stunt.io:8888/doesn't seem
> to work with Chromium.
What version of Chromium are you using?
> Keep up the great work,
_making_ a package isn't particularly easy. I appreciate your giving
it a try.
Todd
Stephen Gigante
May 21, 2012, 1:35:39 AM5/21/12
to Todd Sundsted, MOO Talk
On Mon, May 21, 2012 at 12:48 PM, Todd Sundsted <todd.s...@gmail.com> wrote:
> Packages like LambdaCore aren't going to be static, the objects won't
> remain untouched after install. I will have to change and tweak code
> all over the place when implementing new features. How can i share
> these modifications with other MOOs based on Stunt+LambdaCore?
My assumption is that packages will be static and changes made
directly to package objects will not be preserved when a package is
upgraded. There is no provision for extracting (or preserving)
changes made directly to a package (in a diff, for example) short of
exporting the entire package. If you're tweaking a package like
LambdaCore itself, you'll need to distributes your tweaks as part of a
release of the entire package.
The problem is that legacy cores like LambdaCore weren't designed to
be modular, and my packaging solution doesn't overcome that. Can you
implement your changes as/to children of the objects in the LambdaCore
package, and distribute a lambdacore_extensions package?
I've made quite a few tweaks to core lambdacore pieces, a major stunt related one being adding a catch to $prog:@list to pass to $composed if needed, as well as tweaking @show to handle properties from secondary parents. These kinds of things just don't work by putting them on children. (Note that I have made most of my modifications to $room and the like to children, and then redirected the #0 property to the child, and that works perfectly for me.
> * What happened to $composed:audit() that's mentioned in the "Hoisting
> Lambdacore" article?I removed audit() because it wasn't ready for prime time. It will
make it's appearance in a separate package.
I've been using the @dumps from the same article, which do contain :audit, and while it's a bit messy, and doesn't warn you about verb and property owners [ I got frustrated and hacked :export to automatically fix those for me anyway], I found it was a useful verb.
> Keep up the great work,Thanks! Package support is far from perfect, and the process of
_making_ a package isn't particularly easy. I appreciate your giving
it a try.
I've made a few packages so far, importing things from my old cores to my new one. My only issue is that composed seems to be forgetting packages are installed, which is very concerning for me.
- Stephen
Todd Sundsted
May 21, 2012, 6:34:59 AM5/21/12
to MOO Talk
On May 21, 1:35 am, Stephen Gigante <yeoldest...@gmail.com> wrote:
> On Mon, May 21, 2012 at 12:48 PM, Todd Sundsted <todd.sunds...@gmail.com>wrote:
>
> I've made quite a few tweaks to core lambdacore pieces, a major stunt
> related one being adding a catch to $prog:@list to pass to $composed if
> needed, as well as tweaking @show to handle properties from secondary
> parents. These kinds of things just don't work by putting them on
> children. (Note that I have made most of my modifications to $room and the
> like to children, and then redirected the #0 property to the child, and
> that works perfectly for me.
I'd love to see these collected up and introduced into a new version
>
> I've made quite a few tweaks to core lambdacore pieces, a major stunt
> related one being adding a catch to $prog:@list to pass to $composed if
> needed, as well as tweaking @show to handle properties from secondary
> parents. These kinds of things just don't work by putting them on
> children. (Note that I have made most of my modifications to $room and the
> like to children, and then redirected the #0 property to the child, and
> that works perfectly for me.
of the lambdacore package itself!
> I've been using the @dumps from the same article, which do contain :audit,
> and while it's a bit messy, and doesn't warn you about verb and property
> owners [ I got frustrated and hacked :export to automatically fix those for
> me anyway], I found it was a useful verb.
> I've made a few packages so far, importing things from my old cores to my
> new one. My only issue is that composed seems to be forgetting packages
> are installed, which is very concerning for me.
when that happens? Also, what is your kernel version?
Todd
Todd Sundsted
May 21, 2012, 10:36:12 AM5/21/12
to MOO Talk
Thinking about this more, in the case of tweaks to a package that
aren't meant to be distributed with the package, I propose putting
them in a separate package that "edits" the main package when it is
installed. This could be as simple as an `after_install()' verb that
replaces existing verbs with new verbs.
The advantage is that all mods are tracked in the new package and can
be distributed Nf reapplied at will.
Todd
> * The interactive command line onhttp://stunt.io:8888/doesn't seem
aren't meant to be distributed with the package, I propose putting
them in a separate package that "edits" the main package when it is
installed. This could be as simple as an `after_install()' verb that
replaces existing verbs with new verbs.
The advantage is that all mods are tracked in the new package and can
be distributed Nf reapplied at will.
Todd
d. kajsh
May 21, 2012, 5:50:32 PM5/21/12
to MOO-...@googlegroups.com
Hmm, one example I can think of, where existing objects of other
packages would have to be modified, would be the implementations of
MCP (http://www.awns.com/mcp/README) and SunNet
(http://www.twyst.org/sunnet/sunnet.txt). Both require different
modifications to verbs like #0:user_created, #0:user_connected,
#0:user_disconnected, etc.
How could I package that up in a way that both packages can be
installed and removed independently from each other?
>> * The interactive command line on http://stunt.io:8888/doesn't seem
>> to work with Chromium.
>
>What version of Chromium are you using?
Chromium 19.0.1084.46. I looked at it again and realized that after
allowing Flash on the page, everything worked just fine. (But
shouldn't the application try to fall back to WebSockets or long-
polling if Flash is blocked?)
By the way, again off-topic, but I thought I'd throw it in as well:
When building the server, I couldn't get it to compile without messing
with the Makefile and autoconf stuff first. Whereas GammaMOO compiles
without problems on my system simply by running autoconf, ./configure
and make. Because I'm not good with autoconf, I just merged the
commits 93061478bb and 04c7620263 from GammaMOO and it compiled
flawlessly. Maybe pulling in some of the improvements that have been
made for GammaMOO would be a good idea?
Daniel
Todd Sundsted
May 21, 2012, 8:42:24 PM5/21/12
to MOO Talk
/Nf/and/
Todd Sundsted
May 21, 2012, 9:02:46 PM5/21/12
to MOO Talk
Daniel,
On May 21, 5:50 pm, "d. kajsh" <hsja...@hotmail.com> wrote:
> Hmm, one example I can think of, where existing objects of other
> packages would have to be modified, would be the implementations of
> MCP (http://www.awns.com/mcp/README) and SunNet
> (http://www.twyst.org/sunnet/sunnet.txt). Both require different
> modifications to verbs like #0:user_created, #0:user_connected,
> #0:user_disconnected, etc.
>
> How could I package that up in a way that both packages can be
> installed and removed independently from each other?
When I built the checkpointer package from the original source (http://
lisdude.com/moo/checkpointer.moo), I added a `after_install()' verb to
the checkpointer package object. The verb edited verbs on `$sysobj',
inserting the appropriate code. A companion `before_uninstall()' verb
removed the code.
This isn't ideal, however, it's probably the best we can do with
legacy code, without re-engineering. Re-engineering some of the code,
and making the lambdacore package deal with modular extension in
places like `$sysobj:server_started()' is probably the right long-term
approach. Then add-on packages can just hook/unhook themselves
without resorting to code edits.
And like a said in my response to Stephen, if there are bug fixes to
LambdaCore itself, to make it play better with Stunt, I'd love to see
those rolled into the lambdacore package. Perhaps you and Stephen
could collaborate on an improved release. I think a lot of people
would love to see a LambdaCore NG.
> >> * The interactive command line onhttp://stunt.io:8888/doesn'tseem
> >> to work with Chromium.
>
> >What version of Chromium are you using?
>
> Chromium 19.0.1084.46. I looked at it again and realized that after
> allowing Flash on the page, everything worked just fine. (But
> shouldn't the application try to fall back to WebSockets or long-
> polling if Flash is blocked?)
I have code that does exactly that, but I haven't had time to update
the demo site, unfortunately. It's integrated into Improvise.
> By the way, again off-topic, but I thought I'd throw it in as well:
> When building the server, I couldn't get it to compile without messing
> with the Makefile and autoconf stuff first. Whereas GammaMOO compiles
> without problems on my system simply by running autoconf, ./configure
> and make. Because I'm not good with autoconf, I just merged the
> commits 93061478bb and 04c7620263 from GammaMOO and it compiled
> flawlessly. Maybe pulling in some of the improvements that have been
> made for GammaMOO would be a good idea?
I'm totally open to snapping up other people's code :-) Upgrading
autoconf is on my list, but never quite makes it to the top. I'm
taking a look at those commits as I finish writing this. Thanks!
Todd
On May 21, 5:50 pm, "d. kajsh" <hsja...@hotmail.com> wrote:
> Hmm, one example I can think of, where existing objects of other
> packages would have to be modified, would be the implementations of
> MCP (http://www.awns.com/mcp/README) and SunNet
> (http://www.twyst.org/sunnet/sunnet.txt). Both require different
> modifications to verbs like #0:user_created, #0:user_connected,
> #0:user_disconnected, etc.
>
> How could I package that up in a way that both packages can be
> installed and removed independently from each other?
lisdude.com/moo/checkpointer.moo), I added a `after_install()' verb to
the checkpointer package object. The verb edited verbs on `$sysobj',
inserting the appropriate code. A companion `before_uninstall()' verb
removed the code.
This isn't ideal, however, it's probably the best we can do with
legacy code, without re-engineering. Re-engineering some of the code,
and making the lambdacore package deal with modular extension in
places like `$sysobj:server_started()' is probably the right long-term
approach. Then add-on packages can just hook/unhook themselves
without resorting to code edits.
And like a said in my response to Stephen, if there are bug fixes to
LambdaCore itself, to make it play better with Stunt, I'd love to see
those rolled into the lambdacore package. Perhaps you and Stephen
could collaborate on an improved release. I think a lot of people
would love to see a LambdaCore NG.
> >> * The interactive command line onhttp://stunt.io:8888/doesn'tseem
> >> to work with Chromium.
>
> >What version of Chromium are you using?
>
> Chromium 19.0.1084.46. I looked at it again and realized that after
> allowing Flash on the page, everything worked just fine. (But
> shouldn't the application try to fall back to WebSockets or long-
> polling if Flash is blocked?)
the demo site, unfortunately. It's integrated into Improvise.
> By the way, again off-topic, but I thought I'd throw it in as well:
> When building the server, I couldn't get it to compile without messing
> with the Makefile and autoconf stuff first. Whereas GammaMOO compiles
> without problems on my system simply by running autoconf, ./configure
> and make. Because I'm not good with autoconf, I just merged the
> commits 93061478bb and 04c7620263 from GammaMOO and it compiled
> flawlessly. Maybe pulling in some of the improvements that have been
> made for GammaMOO would be a good idea?
autoconf is on my list, but never quite makes it to the top. I'm
taking a look at those commits as I finish writing this. Thanks!
Todd
Todd Sundsted
May 21, 2012, 9:33:45 PM5/21/12
to MOO Talk
What OS are you running into trouble compiling on, btw...?
Stephen Gigante
May 23, 2012, 8:14:26 AM5/23/12
to Todd Sundsted, MOO Talk
I'm going to work on a basic 'Stunt compatible' lambdacore package over the next couple days, and then once I've packaged and uploaded that, I'll start to get my modular $room code into a decent state and start applying it to other objects that could probably use
I also have a few tweaks that should probably be applied to the Kernel package (Applying the #0:server_started multiloader to the user_[dis]connected verbs, which was pretty useful in getting my MCP package working properly).
One question I have is how stunt handles the upgrading of packages. (If I were to upgrade lambdacore on my MOO, would children transition correctly? Would all my players become children of #-1, or children of the new $prog, but with properties cleared, or would they transition cleanly?)
- Stephen
I also have a few tweaks that should probably be applied to the Kernel package (Applying the #0:server_started multiloader to the user_[dis]connected verbs, which was pretty useful in getting my MCP package working properly).
One question I have is how stunt handles the upgrading of packages. (If I were to upgrade lambdacore on my MOO, would children transition correctly? Would all my players become children of #-1, or children of the new $prog, but with properties cleared, or would they transition cleanly?)
- Stephen
--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To post to this group, send email to MOO-...@googlegroups.com.
To unsubscribe from this group, send email to MOO-talk+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.
Todd Sundsted
May 23, 2012, 8:59:15 AM5/23/12
to MOO Talk
Stephen, do you mean: $user_created(player), $user_connected(player)
and $user_reconnected(player)? I'm building the next release of the
kernel -- I can add those. Any others?
The package manager, Composed, doesn't currently handle upgrades. I
wanted to see if there was any uptake on the idea of packaging MOO
code before tackling that problem. I currently keep all of my
application objects (players, etc.) in a package; I export/uninstall
that before replacing/upgrading other packages, and then import/
install it after the upgrade is complete. It's clumsy, I agree, but
it does work until a better solution is in place.
I'm going to reply in more detail, but first I want to post some
documentation on Shapes, the serialization/deserialization code, and
Composed, the package manager. If everyone understands the substrate
that package management is built on, I think it will be easier to
discuss the current capabilities and plan for future improvement.
Todd
On May 23, 8:14 am, Stephen Gigante <yeoldest...@gmail.com> wrote:
> I'm going to work on a basic 'Stunt compatible' lambdacore package over the
> next couple days, and then once I've packaged and uploaded that, I'll start
> to get my modular $room code into a decent state and start applying it to
> other objects that could probably use
>
> I also have a few tweaks that should probably be applied to the Kernel
> package (Applying the #0:server_started multiloader to the
> user_[dis]connected verbs, which was pretty useful in getting my MCP
> package working properly).
>
> One question I have is how stunt handles the upgrading of packages. (If I
> were to upgrade lambdacore on my MOO, would children transition correctly?
> Would all my players become children of #-1, or children of the new $prog,
> but with properties cleared, or would they transition cleanly?)
>
> - Stephen
>
and $user_reconnected(player)? I'm building the next release of the
kernel -- I can add those. Any others?
The package manager, Composed, doesn't currently handle upgrades. I
wanted to see if there was any uptake on the idea of packaging MOO
code before tackling that problem. I currently keep all of my
application objects (players, etc.) in a package; I export/uninstall
that before replacing/upgrading other packages, and then import/
install it after the upgrade is complete. It's clumsy, I agree, but
it does work until a better solution is in place.
I'm going to reply in more detail, but first I want to post some
documentation on Shapes, the serialization/deserialization code, and
Composed, the package manager. If everyone understands the substrate
that package management is built on, I think it will be easier to
discuss the current capabilities and plan for future improvement.
Todd
On May 23, 8:14 am, Stephen Gigante <yeoldest...@gmail.com> wrote:
> I'm going to work on a basic 'Stunt compatible' lambdacore package over the
> next couple days, and then once I've packaged and uploaded that, I'll start
> to get my modular $room code into a decent state and start applying it to
> other objects that could probably use
>
> I also have a few tweaks that should probably be applied to the Kernel
> package (Applying the #0:server_started multiloader to the
> user_[dis]connected verbs, which was pretty useful in getting my MCP
> package working properly).
>
> One question I have is how stunt handles the upgrading of packages. (If I
> were to upgrade lambdacore on my MOO, would children transition correctly?
> Would all my players become children of #-1, or children of the new $prog,
> but with properties cleared, or would they transition cleanly?)
>
> - Stephen
>
Stephen Gigante
May 23, 2012, 10:14:15 AM5/23/12
to Todd Sundsted, MOO Talk
The ones I've implemented are
user_created user_connected user_disconnected user_client_disconnected user_reconnected
do_out_of_band_command is a tricky one, but I think it's probably best to implement that too (although I'd say halt on a true return value, rather than cycling through all of them)
One other thing I changed in kernel was a hackjob passthrough to allow calling of the other lambdacore $login verbs. You should probably find a nicer way to handle non-connect verbs from the login screen than a simple "***Invalid***" ;)
- Stephen
user_created user_connected user_disconnected user_client_disconnected user_reconnected
do_out_of_band_command is a tricky one, but I think it's probably best to implement that too (although I'd say halt on a true return value, rather than cycling through all of them)
One other thing I changed in kernel was a hackjob passthrough to allow calling of the other lambdacore $login verbs. You should probably find a nicer way to handle non-connect verbs from the login screen than a simple "***Invalid***" ;)
- Stephen
Reply all
Reply to author
Forward
0 new messages