User:Enus Linden/Office Hours/2008 December 19

[9:32] Saijanai Kuhn: anyway, wait another minute than start, I guess
[9:32] Sea Urchin: beanbag: Going to next texture.
[9:32] Sea Urchin: beanbag: Going to next texture.
[9:32] Sea Urchin: beanbag: Going to next texture.
[9:32] Sea Urchin: beanbag: Going to next texture.
[9:32] Sea Urchin: beanbag: Going to next texture.
[9:33] Yuu Nakamichi: hi folks.
[9:33] Tammy Nowotny: hello Yuu
[9:33] Tammy Nowotny: sorry Thoth
[9:34] Morgaine Dinova: Hiya Yuu
[9:34] Morgaine Dinova: OK, you might as well kick off a pre-meeting them Sai
[9:35] Morgaine Dinova: then*
[9:35] Saijanai Kuhn: OK, intro:
[9:35] Sea Urchin: beanbag: Going to next texture.
[9:35] Sea Urchin: beanbag: Going to next texture.
[9:35] Saijanai Kuhn: pyogp is a second life client written entirely in python: [1]
[9:36] Saijanai Kuhn: its completely barebones right now. The most you get is login (either to SL or openSim) or to teh gridnaut Agent Domain so you can TP between OPenSim and SL
[9:36] Morgaine Dinova: Somebody res a chair for Dahlia :-)
[9:36] Saijanai Kuhn: BUT, its a complete do nothing client. Handls all packets
[9:36] Dahlia Trimble: is lagging and cant see the people sitting in the chairs
[9:36] Mirt Tenk: Xugu!
[9:37] Xugu Madison: Hi :)
[9:37] Saijanai Kuhn: our next stage with pyogp is to create a interface for it. I'm proposing we create an AppleScript-like interface that allows one to send general commands via a command file, a script or a GUI
[9:37] Tammy Nowotny: so all we have to do is add all the bugs and find ways to make it crash for no good reason
[9:37] Morgaine Dinova: Hehe
[9:37] Saijanai Kuhn: the format for these commands is "command_name": argument_list
[9:38] Saijanai Kuhn: and whether its what the GUI sends or what a script sends, it all ends up going through the event handler
[9:38] Morgaine Dinova: Er, the format of commands is the least of the issues ;-)
[9:38] Saijanai Kuhn: so you can do any GUI command from a script
[9:38] Saijanai Kuhn: well, a format for the commands
[9:38] Saijanai Kuhn: the point is that you have a name and a parameter list. Scripting is done outside the program or at least can be
[9:39] Saijanai Kuhn: its completely language neutral and if you design the commands right, its program neutral also
[9:39] Khepri Ra: BTW: enus isn't really here yet, but a proxy is
[9:39] Morgaine Dinova: Righto Khepri, cool ;-)
[9:39] Saijanai Kuhn: hey Ingonito Fearless Leader
[9:39] Khepri Ra: hola
[9:39] Phillip Vought: A common way to do this (the way MYSQL and MQ does it) have a master executable that processes stdin for commands
[9:39] Khepri Ra: i won't be engaged for a while yet
[9:40] Saijanai Kuhn: Phillip, as long as you have a connection to the event-handler, it can come from anywhere, including an http server
[9:40] Saijanai Kuhn: or a webclient or whatever
[9:40] Phillip Vought: exactly.. but if you keep it simple crossplatform is easy
[9:41] Phillip Vought: just have a command processor and have the gui use it ;)
[9:41] Saijanai Kuhn: the poitn is to design the commands so they can be used by any mechanism (e.g. GUI, commandline, etc)
[9:41] Saijanai Kuhn: the commands we'd like to support (at first) are the standard GUI commands for the SL client
[9:41] Phillip Vought: do any of the commands need to be stateful?
[9:41] Morgaine Dinova: Phillip: this is architecture of how we're planning it for the Imprudence viewer: [2]
[9:41] Saijanai Kuhn: that's part of the problem space
[9:42] Phillip Vought: Thanks Morgaine
[9:42] Saijanai Kuhn: the way applescript does it is: select the first word of the 5th paragraph of the 4th page of the document "my essay"
[9:42] Saijanai Kuhn: set selection to bold
[9:42] Saijanai Kuhn: so you can "get" parameters as well as set them
[9:43] Tammy Nowotny: are there any undocumented commands which are not in the standard menus and/or any which are in the menus but may be discontinued in the future?
[9:43] Morgaine Dinova: We're not intending to use Sai's current proposal, because the commandline interface is not rich enough for internal datatypes.
[9:43] Saijanai Kuhn: another language might do it in one step: myWordprocessor.page[3].paragraph[4].word[0].set(bold)
[9:44] Morgaine Dinova: Basically Applescript's approach is a glorified Unix shell commandline.
[9:44] Saijanai Kuhn: morgain right. This is strictly for GUI type stuff, but a plugin could use it as well
[9:45] Morgaine Dinova: There's nothing *wrong* with a glorified Unix shell commandline, btw ... it's just that it makes it extremely hard to pass complex datatypes.
[9:45] Saijanai Kuhn: right. for GUIs its a pretty good fit. for something more complex like generalized plugins, well the plugin can use it for the GUI-related part
[9:46] Saijanai Kuhn: but golly, anything you can do with teh client, can in theory, be scripted this way, and you're not tied to a particular syntax or GUI format
[9:47] Saijanai Kuhn: and you can record user actions just by recording the event/parameterlist to a file
[9:47] Dahlia Trimble: one idea we've discussed for Idealist is to allow a new ui definition to be downloaded from a region so a region could have a themed UI
[9:47] Phillip Vought: give me regular expressions and a bash shell and I'll get you most anything you want ;)
[9:47] Morgaine Dinova: Dahlia: like skinning
[9:47] Dahlia Trimble: ya like skinning :)
[9:47] Morgaine Dinova: But we're going far beyond that with plugins
[9:48] Saijanai Kuhn: dahlia, that's great but the scripting part goes behind the scenes. with this model, you'd download the UI and any new commands/callbacks
[9:48] Dahlia Trimble: if the plugins can be controlled by the region
[9:48] Phillip Vought: For example Bryn Oh.s sim Immersiva asks you to change the sky settings.. a plugin could do it for you
[9:48] Saijanai Kuhn: your scripting language could use the command/callback part without touching the GUI, of course
[9:48] Freemason Magic: Does this Message API connects to MQSeries
[9:49] Phillip Vought: Whee.. I think SOAP is a bit much to ask right now ;)
[9:49] Saijanai Kuhn: this can be mplemented in python in a very few lines of code (more for more secure/robust error checking)
[9:49] Morgaine Dinova: SOAP rides on HTTP, we're doing something much lower level, aka faster
[9:50] Saijanai Kuhn: BUT, it gives a universal scripting interface for any client that can handle the commands
[9:50] Sea Urchin: beanbag: Going to next texture.
[9:50] Saijanai Kuhn: and its extensible for custom clients (other clients can't use those commands of course)
[9:50] Saijanai Kuhn: and plugins can use the same comands as the GUI
[9:51] Morgaine Dinova: Sai: not quite
[9:51] Saijanai Kuhn: though not the other way around without extra work
[9:51] Freemason Magic: including MQseries Clients
[9:51] Saijanai Kuhn: Morgaine, which part "not quite"?
[9:52] Saijanai Kuhn: ?
[9:52] Morgaine Dinova: Well, the "not quite" refers to the fact that it would be a special case for a plugin command to invoke one of yours. It would have to use a command that is bound to a handler at your end which just takes the arguments, pokes them into a commandline, and fires it into your system.
[9:53] Saijanai Kuhn: well any plugin worth its salt would know how to connect to the event handler, one way or another
[9:53] Morgaine Dinova: "List of arguments" is not the same thing as a single commandline.
[9:53] Saijanai Kuhn: it would be a base part of the plugin api
[9:53] Sea Urchin: beanbag: Going to next texture.
[9:53] Sea Urchin: beanbag: Going to next texture.
[9:54] Sea Urchin: beanbag: Going to next texture.
[9:54] Saijanai Kuhn: well, a comandline is a limited version of this
[9:54] Phillip Vought: are all the communications going to be XML?
[9:54] Morgaine Dinova: Yeah, but it's a subcase. And I don't like that subcase because it would make scripts that work for your system different to those that work with ours. I was looking for commonality ... and that requires your commandline requirement not to be visible at the plugin API.
[9:54] Saijanai Kuhn: the connection is to the same handler (with or without security issues) that the GUI itself uses
[9:55] Saijanai Kuhn: we were talking json syntax perhaps since almost every language has a JSON interpreter now
[9:55] Morgaine Dinova: Phillip: no. The *least* efficient serialization we're contemplating is JSON. XML isn't even being considered.
[9:56] Saijanai Kuhn: morgaine, its a subcase simply because plugins do more than GUIs do
[9:56] Dahlia Trimble: much as I hate XML, it is widely supported :/
[9:56] Saijanai Kuhn: butr if a GUI or commandfile or script is able to use it, it would be silly for a plugin to ignore it if its there
[9:56] Phillip Vought: what's the reason for the performance requirement? bearing in mind how powerful SL client PCs are?
[9:56] Phillip Vought: XML to an SOA architecture gives you the bus all wrapped up
[9:56] Morgaine Dinova: Sai: Yeah, but that's a reason for you to implement the flattening into a commandline in your handlers, and not to have it appear in the plugin.
[9:57] Saijanai Kuhn: eh, just general easy. There's no reason why xml can't be supported as well. JSON and XML are equivalent for this use, as far as I know
[9:57] Phillip Vought: then given a choice, XML has wider application and is better understood I think..
[9:57] Saijanai Kuhn: KK. not a big deal from my pserspective
[9:58] Phillip Vought: plus is becomes easy to have interprocess comms using XML and SOAP if you decide to do so
[9:58] Saijanai Kuhn: the format for a given command is going to be durned trival regardless
[9:58] Phillip Vought: do you intend to allow interplugin comms?
[9:58] Saijanai Kuhn: the idea is to make the GUI available using the commands. plugins are a bit more difficult, IMHO
[9:59] Sea Urchin: beanbag: Going to next texture.
[9:59] Morgaine Dinova: Phillip: they would not happen directly, but through the Viewer API callbacks
[9:59] Morgaine Dinova: So the answer is yes.
[9:59] Saijanai Kuhn: plugins is a whole different issue as far as I'm concerned. plugins can use the commands, and a GUI could use the plugin commands through the same general mechanism, if they're publsihed
[9:59] Joel Savard: why does raw performance matter for transport within a viewer scripting api?
[9:59] Joel Savard: per previous comments about performance and overhead
[10:00] Morgaine Dinova: Hiya Joel!
[10:00] Phillip Vought: hrm.. well you want to look at the options.. by using XML you allow the extension of the schema dynamically by allowing plugins to report they support given keys
[10:00] Joel Savard: hi morgaine
[10:00] Morgaine Dinova: Joel: for HUDs and everything else that is high speed
[10:00] Saijanai Kuhn: I dont' see that it doesw. Just easier for me to type {command: list} then do the xml for it
[10:00] Tammy Nowotny: hello Joel
[10:00] Phillip Vought: True Saij, but its easier for the app to tel you what funcs it supports through XML
[10:00] Joel Savard: but easier to use someone else's fully debugged (well mostly ;) parsing library than to manage that yourself... once the semantics grow (which they will :)
[10:00] Saijanai Kuhn: the format of the command stream isn't important. Could handle multiple formats as long as teh protocol is the same
[10:01] Saijanai Kuhn: the format being roughly command_name: arguemtn_list
[10:01] Morgaine Dinova: If someone is desperately wedded to XML and used XML to say "Hello mum", then sure, they can concert the on-the-wire traffic to XML if they want to. I'm not going to do it for them. It gains us nothing.
[10:02] Morgaine Dinova: convert*
[10:02] Joel Savard: and when argument list becomes an array of arrays? ;)
[10:02] Thoth Jantzen: anyone ever consider adaptive c-s parsers..?
[10:02] Saijanai Kuhn: JSON and XML both handle that
[10:02] Thoth Jantzen: (context -sensitive)
[10:02] Morgaine Dinova: Thoth: I'm looking at various fast parsers.
[10:02] Phillip Vought: the advantage of XML is not in the construction of the request, but in the provision of the response
[10:02] Thoth Jantzen: well, there is speed, and there is power.
[10:02] Saijanai Kuhn: another implemetnation detail. the RAL job is defining the command/parameter_list
[10:03] Morgaine Dinova: Phillip: fine. Code it ;-)
[10:03] Phillip Vought: :P
[10:03] Thoth Jantzen: most are limited - type 2 or 3.
[10:03] Phillip Vought: good point ;)
[10:03] Saijanai Kuhn: REAL* job
[10:03] Saijanai Kuhn: morgaine and I were discussing almost the simplest possible command for the viewer: login
[10:04] Saijanai Kuhn: even that exposes some issues that wll get more complicated by far with more complicated commands
[10:04] Thoth Jantzen: it depends on how u build it.
[10:04] Saijanai Kuhn: what gets sent over teh comand event handler for a simple login?
[10:04] Thoth Jantzen: that is not always the case.
[10:04] Saijanai Kuhn: login: name,password?
[10:04] Joel Savard: grid?
[10:04] Saijanai Kuhn: login:name,password,destination?
[10:04] Joel Savard: options?
[10:04] Saijanai Kuhn: right
[10:05] Morgaine Dinova: Login is actually a very complex case, I wouldn't recommend one starts from there just because it's the first action. Login is complex because currently we have various alternative login and auth systems.
[10:05] Saijanai Kuhn: and what is stored in the viewer, or in a sim or agent domain/hypergrid and what needs to be sent though the command lien?
[10:05] Phillip Vought: sim to sim TP might be a place to start?
[10:06] Morgaine Dinova: Try something simple: like a world travel logger, with playback (ignoring TP on playback).
[10:06] Saijanai Kuhn: also a complex case wth classic SL though the AD version (not sure about HyperGrid) is quite trivial
[10:06] Joel Savard: wouldn't design of an object architecture be the place to start? ;)
[10:06] Morgaine Dinova: Joel: I haven't cracked immortality yet, so no ;-)
[10:06] Mirt Tenk: lol
[10:06] Joel Savard: hehe
[10:07] Saijanai Kuhn: for teh command system, yes, but this needs to fit existing and unheard of clients as well, so its going to be a cycle of design
[10:07] Phillip Vought: Guys please forgive me for my direction.. I'm kinda used to very big dev teams ;) I forget that this is all volunteer and shoestring :)
[10:07] Joel Savard: yeah, it's always faster to build it and then try to handle the wrath of an installed base when you change it :)
[10:07] Saijanai Kuhn: any command will either need to be standaloen, assume that ALL clients have the data, or allow you to get data from the client to fill in the blanks
[10:07] Phillip Vought: and Joel, thats the problem LL has with their client right now ;)
[10:07] Morgaine Dinova: Phillip: so was Apache "shoestring". And Linux ;-)
[10:08] Enus Linden: so Khepri here kept me up to date, kinda... what exactly is our topic and angle atm?
[10:08] Morgaine Dinova: Enus: wb
[10:08] Khepri Ra: waves
[10:08] Joel Savard: yup - just poking at the assumptions for conversation's sake
[10:08] Morgaine Dinova: Just presenting ideas
[10:08] Phillip Vought: Yes Morgaine.. the Cathedral and the Bazzar ;)
[10:09] Saijanai Kuhn: issue of command state held in client vs contained in the paramter list or held in the AD or sim or whatever
[10:09] Saijanai Kuhn: what does a given comand have to say?
[10:09] Morgaine Dinova: Yep, it's a good hammering at various things about it all. Which is great, beat it hard now to make the problems fall out
[10:09] Phillip Vought: if you can be stateless it would really really help the maintenance :)
[10:09] Saijanai Kuhn: a GUI callback can assume an awful lot of state info, which an external script/commandfile can't
[10:09] Enus Linden: is going to have to read meeting notes closely methinks
[10:09] Morgaine Dinova: Phillip: we were talking about that with Sai, funnily enough --- keeping all state in the plugins would be grand, for the viewer.
[10:10] Saijanai Kuhn: exmpale for login: destination: home/last/region/x/7/z
[10:10] Saijanai Kuhn: if that is an option for the lgin we have to assume the cliebnt knows what "home" means
[10:10] Saijanai Kuhn: as well as "last"
[10:11] Joel Savard: hmm home is not a client-stored item though is it?
[10:11] Enus Linden: not afaik
[10:11] Enus Linden: is server side
[10:11] Enus Linden: client says "tp home"
[10:11] Joel Savard: you can go to a different computer and say "home" and you go home :)
[10:11] Saijanai Kuhn: not currently. ts stored by the login server for SL and SHOULD be part of the AD in someway eventually for OGP
[10:11] Morgaine Dinova: Home is actually superfluous, except when server-side fails.
[10:12] Saijanai Kuhn: but it points out the design issue: what stuff does the command have to include and what can be assumed?
[10:12] Morgaine Dinova: Ie. everything is simply landmarks. If you want to alias one of them to "Home", great ... but it's not fundamental
[10:13] Saijanai Kuhn: which means that the client has to be able to provide state info for some commands
[10:13] Saijanai Kuhn: "getHomeRegion:NULL"
[10:13] Saijanai Kuhn: or something
[10:13] Joel Savard: <- isn't quite sure of the current focus of this discussion...
[10:13] Phillip Vought: the client doesnt need to KEEP the state, just know where to get it from
[10:13] Tammy Nowotny: will all future SL-like worlds even have a home location?
[10:13] Enus Linden: are we talking about pyogp clients, or viewer clients, or or or?
[10:14] Saijanai Kuhn: right, I'm just using it as an example for how choice of parameters in the command may not be straightforward
[10:14] Saijanai Kuhn: your GUI callback CAN know or assume state info because the programmers say so
[10:14] Phillip Vought: hehe.. thats why I suggested XML :) it does complicated ;)
[10:14] Saijanai Kuhn: so does JSON. not the issue here
[10:14] Morgaine Dinova: Well we can certainly except that plugins will have dedicated storage roles as well as behavioural roles. So if there's a landmarks plugin, then we can expect any other plugin (or internal viewer code) that refers to a destination name to cause a callback to the landmarks plugin accessor.
[10:15] Morgaine Dinova: expect*
[10:15] Saijanai Kuhn: however its sent over the wire (or via GUI callback), you gotta know what to send in the first place
[10:15] Phillip Vought: not only that, but your plugin has to know about the landmark plugin and know what functions it makes available
[10:16] Morgaine Dinova: Enus: when I mean plugin, I say "plugin". If I say "client", I mean the composite of client + its constellation of plugins.
[10:16] Saijanai Kuhn: Morgaine, right, but without that landmark plugin, you'd need to "getLandmark:x, uselandmark:placeeholder_for_get
[10:17] Morgaine Dinova: Sure, but the resolver for "x" is either the default handler for landmark resolution, or a plugin which has taken that role.
[10:17] Saijanai Kuhn: wher e"placeholder_for_get" can be anything
[10:18] Joel Savard: <- has always wanted the option to log in with "avatar xyz" rather than having to change once appearing.. that might make things more interesting, eh?
[10:18] Saijanai Kuhn: the last info "getted"
[10:18] Phillip Vought: but what do you do in the case when you're adding a new function, not replacing an old one?
[10:18] Morgaine Dinova: Only the "getLandmark" function knows that its argument is a landmark, so only it can place the right resolution call.
[10:18] Tammy Nowotny: thatqmight fix the Ruthing/Caspering probelm too, Joel :-)
[10:18] Saijanai Kuhn: well then uselandmark:getlandmark()
[10:19] Joel Savard: huh... how would it fix that, tammy?
[10:19] Joel Savard: by forcing a re-acquire of assets on login rather than a cache pull?
[10:19] Saijanai Kuhn: the only functin that mighg be handled by the scripting API itself
[10:19] Saijanai Kuhn: automatically refer to teh last bit of "got" info
[10:20] Saijanai Kuhn: there's no doubt an official programming term for that
[10:20] Joel Savard: what kinds of plug-ins do you think ppl would build, if they could?
[10:21] Morgaine Dinova: We have a first-shot list of typical ones, Joel
[10:21] Phillip Vought: first one I'd workon is a login/logout without quitting the app :) simple and useful ;)
[10:21] Morgaine Dinova: [3]
[10:21] Saijanai Kuhn: that's morgaine's topic. Im just interested in desinging a scripting thing pyogp can use (that otehrs can copy without issues)
[10:22] Joel Savard: heh
[10:22] Sea Urchin: beanbag: Going to next texture.
[10:22] Morgaine Dinova: Wrong URL, lol
[10:22] Morgaine Dinova: Sorry, trying again, it should be the wiki
[10:22] Saijanai Kuhn: Philip, the easiest way to do that is to keep all the state info associated with a given avatar in a avatar cxlass that the client refers to
[10:23] Saijanai Kuhn: that way you can have a list of active avatars for the bot scripts to work on (all10K of them, right enus?)
[10:23] Morgaine Dinova: [4]
[10:23] Morgaine Dinova: That's better
[10:23] Tammy Nowotny: I was afk Joel... but that was what I was thinking... it wd force the server to find your shape etc. earlier in the login process
[10:23] Joel Savard: thx morgaine
[10:24] Saijanai Kuhn: there's overlap between what morgaine is talkign about and what I'm talking aboutt. I think MY topic is waay simpler to implement at this poitn ;-)
[10:25] Dahlia Trimble: That wiki page is the list I've been waiting to see :)
[10:25] Saijanai Kuhn: and can be used within Morgain's plugin API
[10:25] Enus Linden: sai, i have 1005 atm on agni
[10:25] Morgaine Dinova: Yes, it's important not to confuse the two.
[10:25] Enus Linden: not running now of course...
[10:25] Saijanai Kuhn: right but ventually, 10K could be useful to test teh entire grid after a restart
[10:26] Morgaine Dinova: We're trying to find commonality so that pluging in Imprudence are identical to PyOGP ones .... obviously that would totally rock.
[10:26] Morgaine Dinova: plugins*
[10:26] Saijanai Kuhn: visuallizes little swarms of texterxxx tester bots TPing throughout secondlife
[10:26] Morgaine Dinova: Yeah
[10:27] Tammy Nowotny: LOL
[10:27] Morgaine Dinova: It would be incredibly powerful for testing
[10:27] Joel Savard: wonders if folks would go for some sort of self-identification protocol for bots.. just an aside... that old question about "how many of these av's are bots"
[10:27] Saijanai Kuhn: morgaine, yeah. Though, my main focus willl be on geting a script API working. Should map directly to the class structure for pyogp since we're starting formt eh ground up
[10:27] Morgaine Dinova: Joel: I'm a bot --- you have a problem with that? ;-)))
[10:28] Joel Savard: <- fails turing administration test :)
[10:28] Saijanai Kuhn: hoping to make it general enough that any client should be able to use it
[10:28] Morgaine Dinova: Hehe
[10:28] Saijanai Kuhn: going back to original intro
[10:29] Saijanai Kuhn: so, the object model for pyogp and teh scripting model will be designed together I think
[10:29] Enus Linden: sai, does that suggest that the class model (OM) in pyogp, which we will be refactoring to *some* unknown degree soon, will match the imprudence plugin api's model?
[10:30] Saijanai Kuhn: not that I intend ;-)
[10:30] Saijanai Kuhn: plugins are way harder to design, IMHO
[10:30] Saijanai Kuhn: I'll be qute happy with just the scripting working
[10:30] Saijanai Kuhn: if we can figure out a plugin API at the same time, great
[10:30] Enus Linden: so pyogp can continue on it's slow, lumbering, happy way?
[10:30] Saijanai Kuhn: I sure hope so
[10:30] Enus Linden: with blinders on?
[10:30] Enus Linden: :)
[10:31] Saijanai Kuhn: right
[10:31] Joel Savard: aren't these fairly tightly coupled design problems though, or am i missing the point?
[10:31] Saijanai Kuhn: ideally, any plugin architecture has to assume that other viewers were designed with out knowing about it
[10:31] Enus Linden: there can naturally be api OM mappings on both sides of any codebase
[10:31] Morgaine Dinova: I dispute that, Sai.
[10:32] Joel Savard: assuming that plug-ins would be scriptable and thus referenceable by some scripting environment
[10:32] Saijanai Kuhn: well, at some level perhaps, but if we do the event handler for hte GUI right, it should automatically be able to handle plgin events, even if we don't know what they'll look like
[10:32] Joel Savard: ok
[10:32] Phillip Vought: you have to define a "broker" or what youre calling the event engine that handles all the direct interfaces to the viewer so that it can be implmented on other viewers easily.. and changes in viewer APIs only need patching in the broker
[10:32] Saijanai Kuhn: I mean, pyogp doesn't have a scengraph defined at this point, or a openGL display area, etc
[10:33] Morgaine Dinova: Sai: your suggestion makes no sense, if you examine it: if a plugin system has to assume that its host isn't tailored for it, then it has to supply the specifics required by that host. That implies that all plugins will be non-portable.
[10:33] Enus Linden: good lord, pyogp doesn't even know what an object is yet
[10:33] Saijanai Kuhn: so kinda silly for us to try to handle those kind of plugins past a "black box level"
[10:34] Morgaine Dinova: Enus: all that means is that PyOGP's Viewer API will not be highly populated yet.
[10:34] Enus Linden: :)
[10:35] Saijanai Kuhn: Enus, right. we don't have anything defined past the basic packet handling. This would be teh event handler for GUI and maybe for higherlevel internal messaging (which coudl be exposed to a GUI or script also)
[10:35] Tammy Nowotny: hey Life!
[10:35] Saijanai Kuhn: I guess layers of design: simple GUI, more complex actions, general plugin
[10:35] LifeFactory Writer: Hello!
[10:36] Saijanai Kuhn: "simple" GUi will be hard enough I suspect
[10:36] Enus Linden: i'd like to assert that the current pyogp.lib.base is going to remain dumb as a rock, and purely library oriented. GUIs, plugins, etc, would be application implementations that depend upon pyogp.lib.base
[10:36] Enus Linden: other packages can be added, pyogp.viewer, pyogp.plugin, etc
[10:36] Saijanai Kuhn: right. the event handler would fit on top of that, and handlers for each event registered through it
[10:37] Enus Linden: but what we are working with today is much more fundamental than guis etc
[10:37] Saijanai Kuhn: so login dialog box would eventually evoke login command
[10:38] Morgaine Dinova: This isn't really a complex issue: the Plugin API just talks [command, arg1, arg2 ....
[10:38] Saijanai Kuhn: and the same event handler (broker?) would be able to handle commands from the GUI or from a script or whatever
[10:38] Enus Linden: nice explaination morgaine
[10:38] Saijanai Kuhn: yeah, but handlers for scenegraph are going to be more complicated than handlers for TP avatar or move avatar north or whatever
[10:39] Morgaine Dinova: Just a bit, hehe
[10:39] Dahlia Trimble: how important is portability between clients?
[10:39] Morgaine Dinova: And in your case Sai, you can just ignore them with an "No scenegraph, punk" response.
[10:39] Saijanai Kuhn: could all be handled by the same event thing, or split off in some way
[10:40] Morgaine Dinova: Dahlia: hard question. I think everyone would prefer to be able to use the same plugins everywhere though
[10:40] Saijanai Kuhn: well, for basic GUI actions, should be universal
[10:40] Phillip Vought: the ultimate choice for implementations lies with those with the ability to code, so they get the votes, but I suggest that whatever is implemented is extensible and has as few direct "hooks" as possible.. and oyu have that with the handler
[10:40] Dahlia Trimble: I think they would, but it mau be extremly difficult to implement
[10:41] Saijanai Kuhn: right. Though, the model works perfectly for GUIs without any mods. Handlign plugins may or may not be possible. Implementation details for the reader, etc
[10:42] Morgaine Dinova: Dahlia: it's mostly a human/social problem. If I insist that the command name "getPosition" means return av coordinates, and someone else insists that that command should make the tea, then we have a problem. But it's a human one.
[10:42] Enus Linden: RL beckons to me atm folks...
[10:42] Dahlia Trimble: portability also asumes the plugin architecture was properly designed the first time
[10:42] Morgaine Dinova: KK Enus, have fun :-)
[10:42] Joel Savard: see you enus
[10:42] Dahlia Trimble: bye Enus :)
[10:42] Saijanai Kuhn: KK ENus, I'll work up the transcrpt when we're done. Thanks for hosting us
[10:42] Enus Linden: hollar at me if i can help the convo in any way further, and feel free to bring it to the OH in future mtgs
[10:42] Tammy Nowotny: Thanks Enus.
[10:42] Tammy Nowotny: TYVM Enus
[10:43] Mirt Tenk: happy holidays
[10:43] Joel Savard: <- hopes for a versioning capability (maybe just a call... but might be more complex depending on the number of moving parts) so that calling code can determine which version of the api it's talking to :)
[10:43] Morgaine Dinova: Joel: ouch. Good point though
[10:44] Black Cat: Doll: ~^.^~ Meow!!! ~^o^~
[10:44] Joel Savard: been there, done that :) put together a team to build an audio analyzer plug-in for pro tools.. keepign up behaviors that worked as they iterated the plug-in host on three platforms was "interesting"
[10:44] Dahlia Trimble: lol
[10:44] Saijanai Kuhn: lots of mysteries here for me. Learning process
[10:44] Morgaine Dinova: Nice :-) And did your plugins work with Ardour too? ;-)
[10:45] Joel Savard: hehe no... "just" Pro Tools Windows/Vista, Pro Tools Mac OS X 10.4/10.5, a proprietary system based on embedded windows, and three versions of the plug-in host environment
[10:46] Tammy Nowotny: Pro Tools? Wasn't that the software which kept Axl Rose occupied for 13 years as he tweaked every note of every guitar solo on his album?
[10:46] Tammy Nowotny: I bet he sued all those versions, Joel.LOL.
[10:46] Joel Savard: heh... it's kinda the microsoft of the pro recording studio market...
[10:46] Saijanai Kuhn: so, for me, the deal is to get a basic scripting/GUI event handler defined, and then populated with simpple command handlers just for a starting point in pyogp
[10:46] Joel Savard: yeah maybe he did sue them :p :)
[10:46] Saijanai Kuhn: and we can work out details of comands, plugin level commands, etc., as time goes on
[10:47] Tammy Nowotny: well he sues everyone. no worries.
[10:47] Joel Savard: hehehe
[10:47] Yuu Nakamichi: he shoulda used digital perferomer then ;-)
[10:47] Morgaine Dinova: Well here we have a bit of a unique opportunity for cross-client portability, by virtue of the fact that we use a socket interface and machine-independent comms format. So it would be a shame to end up with non-portability when we have the opportunity.
[10:47] Joel Savard: ahh yuu... here come the real religious wars!
[10:48] Yuu Nakamichi: ;p
[10:48] Dahlia Trimble: just use Corba and call it quits ;)
[10:48] Saijanai Kuhn: morgaine, I agree. Esiest issues first, though try to design with the harder issues not ruled out, at least
[10:48] Dahlia Trimble: ducks...
[10:48] Joel Savard: heh
[10:48] Saijanai Kuhn: wher'es infinity when you need her?
[10:48] Morgaine Dinova: Dahlia only said that because Infi's not here ^_^
[10:49] Saijanai Kuhn: ;-)
[10:49] Joel Savard: nice to see you guys.. i'm going to have to log into rl for a bit...
[10:49] Saijanai Kuhn: she has a whip...
[10:49] Yuu Nakamichi: take care joel
[10:49] Morgaine Dinova: KK Joel, nice to see you :-)
[10:49] Saijanai Kuhn: Thanks for dropping by Joel. Good points
[10:49] Saijanai Kuhn: ack local chat lag
[10:49] Dahlia Trimble: tc Joel :)
[10:49] Morgaine Dinova: And nice dragon too ;-)
[10:49] Phillip Vought: Well folks.. been nice to meet you all if I can help test or debug, I'll keep an eye on the forum
[10:49] Mirt Tenk: tc ty
[10:50] Dahlia Trimble: ya I think I need to try to make a little money before the day is over, bye all :)
[10:50] Morgaine Dinova: Cya Phillip, take care :-)
[10:50] Tammy Nowotny: I know that feeling Dahlia
[10:50] Yuu Nakamichi: bye dahlia :)
[10:50] Tammy Nowotny: I made 75 cents yestersay. a better day than usual lately.
[10:50] Morgaine Dinova: Cya Dahlia, have fun :-)
[10:51] Tammy Nowotny: cya Daghlia
[10:51] Yuu Nakamichi: laters :-)
[10:51] Saijanai Kuhn: thanks all for coming. I'll post transcript on wiki etc
[10:52] Morgaine Dinova: Tnx Sai
[10:53] Tammy Nowotny: TY Sai
[10:54] lonetorus Habilis: sai, was not following too closely, but there will be possibility to execute a flat text file with commands (w. arguments) in the "commandline" you where speaking of, as in, human acessible?
[10:55] Tammy Nowotny: tiem for me to go, too
[10:55] Tammy Nowotny: I didn;t realize Lindens had \rwal life
[10:56] Joel Savard: ok now that my stack is way too deep... gotta run...
[10:56] Joel Savard: see ya guys
[10:56] Morgaine Dinova: Cya Joel, have fun :-)
[10:56] Saijanai Kuhn: later joel...
[10:56] lonetorus Habilis: kirsten, neat avie btw, and thanks for the various clinet binaries, shadows etc
[10:56] KirstenLee Cinquetti: np just a bit of spare time i had to play with
[10:57] Morgaine Dinova: What is it with the tentacle fixation? ;-)
[10:57] Saijanai Kuhn: Ionetorus, yeah. A simple list of comands with paramters is all that would be handled anyway
[10:57] KirstenLee Cinquetti: appeals to japanese clientele
[10:57] Saijanai Kuhn: scripting is done outside the handler whether by plugin or by an external app
[10:57] Morgaine Dinova: Heh
[10:57] lonetorus Habilis: so it would be possible to script a bot behaviour in a relativly easy way (given propper ref. manual for the comamnds)
[10:58] Saijanai Kuhn: done properly, you just "turn on recording" and the event handler sends the commands to a file as well as to the individual handlers
[10:58] Saijanai Kuhn: so anything the handler knows about, is automatically recorded for playback
[10:58] lonetorus Habilis: kirsten, yeah mantis's stuff is neat, though personally i would go for hern's stuff (AVZ)
[10:58] Saijanai Kuhn: or can be
[10:59] Saijanai Kuhn: did that make sense?
[10:59] lonetorus Habilis: sai, yes, like a macro recorder
[10:59] Saijanai Kuhn: right, except an app-neutral macro
[11:00] Morgaine Dinova: Sai, I have an idea
[11:00] Saijanai Kuhn: OK...
[11:00] lonetorus Habilis: sounds like it might have some powerful usage indeed
[11:01] Saijanai Kuhn: yeah, enus wants pyogp scriptable enough to run hords of WA bots
[11:01] Saijanai Kuhn: QA* bots
[11:01] Saijanai Kuhn: could have "unit tests" for sims
[11:02] Saijanai Kuhn: 40 bots TP into a sim, run a series of tests then TP to the next sim
[11:02] Morgaine Dinova: How about we make one or more standard commands be commandline-oriented? So all plugins can use them on all systems. The handler would determine what is actually done --- in your case it would do what you described.
[11:02] lonetorus Habilis: would be good with a way to interact with it through lsl, make it listen on a channel, for either command execution directly, or just triggering execution of exisitng comamnd files, but i see a few security risks there ;)
[11:02] Saijanai Kuhn: OK
[11:03] Morgaine Dinova: After all, we need such a command to deal with IM input.
[11:03] Saijanai Kuhn: well for pyogp bots, security is up to the implementor. FOr a regular client, same thing I guess. Need to explitily enable commandilne parsing through chat or whateer
[11:03] Saijanai Kuhn: libslproxy (orwhatever its called) does that
[11:04] lonetorus Habilis: yes, but also, trust in who is sending the commands
[11:04] Morgaine Dinova: Ione: PyOGP is just a viewer --- there is no concept of "who" is sending the commands --- it's whoever it logs in as
[11:05] Saijanai Kuhn: sue. That would be a step above the comandline parser, I think. You get it from teh chat log and it checks to see who "said" it whether "self" or an uathorized avie, or some random griefer
[11:06] Morgaine Dinova: ?
[11:06] Saijanai Kuhn: andi fits not "authorized" it doesn't get passed on to the parser
[11:06] Saijanai Kuhn: you could have an avie bot send comands to itself through local chat
[11:06] lonetorus Habilis: yes, what i meant is that a in world scripted object or atatchment on that avatar that its logged in with, could be controlled through commands sent in world via lsl
[11:06] Saijanai Kuhn: or one avie control another
[11:06] Saijanai Kuhn: or a HUD or scripted object or whatever
[11:06] KirstenLee Cinquetti: intresting talk , laters all :)
[11:07] Morgaine Dinova: Cya Kirsten
[11:07] Saijanai Kuhn: libsl already allows that to some extent. THis would be the same deal
[11:07] lonetorus Habilis: sai, sounds very cool indeed, looking forward to seeing working examples
[11:07] Saijanai Kuhn: loking forward to producing them ;-)
[11:07] Morgaine Dinova: I'm still looking forward to just logging in, lol
[11:08] lonetorus Habilis: oh, and good call im'ing the sculpt dev group, or i would never have heard of this ;)
[11:08] Morgaine Dinova: Oh damn, didn't ask Enus if AD is down
[11:08] Saijanai Kuhn: later all posting transcript
[11:08] Saijanai Kuhn: check with Whump, morgain
[11:08] lonetorus Habilis: yes, thank you and have a good evning

User:Enus Linden/Office Hours/2008 December 19

Navigation menu

Search