Lawson English wrote:
Well, that's the thing. Why can't it be generic, at least on some level?
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.
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
abstracting the existing GPL code as well since its the least extensible
and flexible of all the viewers out there.
Because after you've abstracted away all of the differences, you have
nothing left. There are no generic functions out there just waiting for
an API.
You seem to be talking about the message protocol. That is a very small
part of the viewer. If all you want to do is intercept the message
stream, perhaps you should say "generic plugin to the message protocol."
I'm not sure that the word "generic" makes any difference there, but
if you like it, go ahead.
But if you believe that all the viewer does is process messages then you
have a very different understanding of the viewer than I do. Yes, you
can abstract it that way, but all of the work is in the details that are
dismissed by that abstraction.
Mike
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
