On Dec 17, 2008, at 7:48 PM, Lawson English wrote: I am not on sldev myself, and don't think my reply touches scripting nor grids, so removed those 3 groups from the recipients. Feel free to forward this as you please, for further talks pyogp list is fine for me - but also Realxtend, as it is now preparing for work on the new viewer architecture where a generic component system is one of the things to be examined.
> Mike Monkowski wrote: >> Gack! You lost me with the first word of your title: "generic." I >> believe that is a very naive approach. Unless you are specific about >> what kind of functionality you want to provide you will quickly get >> lost. Can I plug in a new render engine? Can I add a plugin that > Well, that's the thing. Why can't it be generic, at least on some > level? I've often voiced the same concern when someone has thought of starting to write a 'general system for things', as it easily ends up being nothing for anything. However, I don't think that is the case here, exactly because we have specific known requirements and furthermore multiple existing systems where they have been implemented. For example, OpenViewer has the renderer as a basically engine independent interface, the current w.i.p. implementation being ogrerenderer.py . OpenSim has been worked on a lot with modularity in mind and the same developers strive to carry it on to viewer projects too (Idealist is still very young, interesting to see where it will go). We took a look at the existing bsd licensed / new from scratch, libomv using, viewers - a draft doc of that is at http://www.playsign.fi/engine/rex/viewerarchs (not posted anywhere yet, will probably move to rex or why not opensim wiki - comments welcome, may have mistakes even (really is a draft in that sense)). Oh and the purpose of that reading is to get more insight to the design problems there are, and of the possible solutions architecture wise - not that much the apps themselves, but trying to learn lessons there. > It's true that rendering plugins would be more difficult to make > generic > than, say, IRC plugins, but there are bound to be features applicable > to > any SL-compatible client, or you wouldn't be talking about a SL plugin. Hm I'm still not sure if I got you correctly there, but yah, exactly because there is a somewhat known feature set to start with, and performance etc. criteria for many of them etc., I find this may well make sense. And, I guess this is what you meant, it's not for just any kind of random applications, but for virtual worlds software components or something. There is the point, though, that we are not restricted to the SL featureset but e.g. OpenSim is an SDK for many kinds of applications, there are components made for Rex that have no counterpart in SL like VLC support (oh well that's just a texture plugin kinda, though) and Flash cutscene animation playback (no correspondence in SL but well just an overlay surface with an animation). But that only emphasizes your point: it's great if we can get some sort of component level interoperability, cross-viewer compatible widgets? And of course plugins for additional network protocols etc., chat dialogs, some sort of outliner view .. what not. What kind of feature set are those people actually thinking for the client scripting API? Must check that thread again and read more I guess. > Right now, all the existing clients are either based directly on the > GPL > code or are reverse engineered to be compatible with the GPL code at > the > protocol level. What is wrong with trying to keep this compatibiltiy at > the plugin level by abstracting away differences? That includes Interesting point. And I guess that's where we want to head anyway, compatibility of components is a worthy goal when the world is diverse anyway. I think many here appreciate standards too, but that is another question and not for these things anyway (plugin apis - I think standards are more in the area of data formats and protocols). > abstracting the existing GPL code as well since its the least > extensible > and flexible of all the viewers out there. Reportedly also a reason why different implementations are desirable.. can't know first hand but am easily trusting the words of others there. >>> Imprudence forum that describes a system that is coincidentally close >>> to what I'd like to see made available in the pyogp viewer. ... this stuff seems to be in the same area where some of the thinking for rexng has gone too, event systems etc. """ On the other hand, Sai already had a multi-dispatch model in mind, in which multiple plugins could express interest in the same event and get notified with appropriate data when the event occurs. We haven't covered events at the Viewer API in Imprudence yet, but clearly we will need that too. Also, Sai's event dispatcher model has default handlers even if no plugin registers interest in an event ... that might be of some use to us as well, possibly as a way of automatically spawning plugins. Anyway, it's worth keeping in mind. """ .. but not to such details even yet. As I mention in that doc: """ [PyOGP] by Linden Labs and the Architecture Working Group (AWG) is another client stack. It is not meant for full viewer clients, but for testing the OGP (Open grid protocol) and coming new protocols around that. It however is non-GPL licensed (bsd-like) and another existing client implementation, and different from the viewers looked at here as it does not use LibOMV, so might be worth a look. """ As you know from before I've been following pyogp for other reasons too, and it's certainly interesting to take a look at the recent developments again now .. also curious because we have been thinking of component architectures and you first used zca, not only zope.interfaces but something else too, or? Well, will see from the source if / when find the time, I think soon enough. > L. ~Toni --~--~---------~--~----~------------~-------~--~----~ this list: http://groups.google.com/group/realxtend realXtend home page: http://www.realxtend.org/ -~----------~----~----~----~------~----~------~--~---
