Public Standards (Technical ones...not "don't burp in the welcome area")

Over the years (ugh too old) in SL I've seen a number of proposals for implementing some standard protocols for some things...

- A generic data protocol (I wrote one, I know a lot of others have too). Nowadays I (and I'm sure others) just use XML, but even XML requires schema/vocabulary for specific functionality.
- A weapons protocol (I talked to another weapons dev a way back about this...not interested).
- A "pet" protocol (dogfights, who knows).

In addition to those ideas, I've never seen any pattern based development suggestions (doesn't mean they don't exist...I've just never seen anybody else talk about them). So, I mocked up an MVC triad and have been working through SL limitations that make it practical or not (I'm finding controllers to be problematic due to the extra communication calls...it's just too slow if you're doing a great deal of messaging, and models are interesting since flexible and durable storage is still tricky in SL) which is leading me to believe that a simpler Observer pattern is the way to go, leveraging adapters and commands for plug-in-able extension. I know a lot of people argue that these things aren't possible in SL since it's not OOP. Suffice to say I have always disagreed, now moreso than ever. However, I'm starting to wonder whether thinking in terms of MVC (even dumbed down) is the way to go; are SL applications applications at all...and if so, what is the fundamental nature of them (instinctively I think presentation/interactivity, which would have you thinking in terms of PAC, MVC, etc...but is this the reality I wonder).

To that end, I'm considering opening up a once a week, or maybe bi-monthly (probably better) user group to discuss what the requirements for a standard comm protocol may be. The reason is I've been considering an overhaul of my weapons system (which is working perfectly but meh a developer can never just leave anything alone) and decided this time to see if I could move towards some SL comm standard for the data; the mHUDS are a perfect candidate for study (since they are 10 modules working cooperatively through a central data mechanism). To be honest, I'm tired of the top-down scripting approach LSL inclines you to take, and want to mature my use of it. You get to a point where you essentially can do anything with LSL scripting fairly quickly, so actually doing it gets sorta redundant...time to think about patterns. This became pretty obvious as I was building out that land scanner (which ultimately bored me). Ok, let me drag on this floater script...now let me drag on my physical linear motion script...now let me drag on my scanners...and so on.

The upsides of this kind of dev are obvious; reusability, consistent methodology, unique implementation but consistent interfaces, and so on.

Downsides I can see: a consistent standard is a target. I guess part of the standard, or a standard in and of itself, would be a method for encryption or obfuscation. I'm not a fan of channel swapping.

Anyway I'm sure that's enough to get some thoughts. FYI, if you can only say, "this will never fly and pattern development discussion is a waste", please start another thread and argue that point there, thanks.

Oh and yes...this does not simply apply to scripters. Builders would have to understand this too (i.e., one of the most frustrating things about one builder I worked with is that she just could not understand why I needed the root object of a model to be oriented to 0,0,0, so decided it was a waste of time, which had me tearing apart every one of the models to structure them so the draggable scripts would work). Anyways, that's why it's not in the scripting forums.

I don't know what you just said, but I like where you're going with it ;0

Please type in English, Tcoz.

This would probably be better suited for the scripting forum.

I'm interested.

I'm assuming the first major thing that will come out of this is, "Ditch the listen system for data transport from point to point."

A genital protocol would be useful as currently all the different brands are incompatible.

As a matter of fact Hiro, one of the issues to sort out would be the transmission, i.e. issues with links vs. listens. I find myself using different techniques based on how the subsystems are physically built; these kinds of things make the need for a framework somewhat more evident (decouple from the physical implementation and all that). I've found that link systems with several objects communicating in real time require a more black box component approach and savvier builders, vs. listens which have no delays of any kind other than system processing. The former makes me distribute my logic more aggressively (so that the objects can do their thing without a callback), the latter to centralize it. Defining issues with both would be interesting.

In either scenario, there should be a way to just have a builder drop in a "view" object (a user UI thing, like a terminal window), reset it, and have it registered with an underlying system to understand and process requests; then a little app API so that people can access the underlying services (say you implemented a standard little lookup table thing so people could easily store name value pairs). A lot of people have set this kind of thing up I'm betting, so finding out the common pattern and wrapping it up for general use seems to be the next step.

Ah the things you think up when you're sitting there waiting for a remote Ant script to finish building.

And hey Eggy I know where the scripting forum is and happily direct you to it. There, you can view posts from people who want to confine the topic entirely to scripters.