[sldev] [VIEWER] SVG on a prim, a HUD, and in the viewer itself as a new GUI...

[Jason Giglio]

Here's an exchange between me and John that was meant for the list but 
went private due to my screwup.

John Hurliman wrote:
> Jason Giglio wrote:
>> John Hurliman wrote:
>>> There is no need to modify the grid to do this. I have made specialty 
>>> prims similar to this for commercial projects (not using SVG though), 
>>> and while it would be much easier with Qarl's custom attributes bits 
>>> it is still possible with what we have today. I think the "we can't 
>>> do anything unless you rewrite the grid" meme was started by people 
>>> who lack imagination. To answer your question about asset uploads, 
>>> some of the asset types do either no checking or very minimal 
>>> checking and it is trivial to embed custom data. If you have specific 
>>> questions about any of it contact me off-list as I'm not sure 
>>> uploading arbitrary assets and mangling prim data are on-topic for 
>>> the list, though I would really like to see a custom client with SVG 
>>> support.
>>>
>>> John Hurliman
>>
>> Jamming this information into a bogus texture isn't really what I'd 
>> call a "ready to go feature".
>>
>> Our goal should be making patches that LL can accept, not hacking our 
>> way through the system creating more "legacy misfeatures" like 
>> invisiprims.
>>
> 
> You can have whatever goal you want, my goal is to implement features 
> that clients request by the deadlines they request them, and it never 
> seems to coincide with the timeline LL has for proposed features.
> 
>> If LL allows corrupt textures now and we start using them for this, 
>> then LL has to accept corrupt textures (or textures for faces that 
>> don't exist) forever.  I don't think that situation benefits LL or us.
> 
> I'm pretty sure they don't have to do anything at all, *especially* not 
> providing lifetime service for a third party feature. The grid changes 
> nearly every week and I am fixing libsecondlife or adding new feature 
> support to it every week to try and keep up. If a hack feature is 
> properly implemented as a real feature I definitely won't be 
> complaining, and it will likely take less time to update the code then 
> it does to write this e-mail.
> 
>>
>> We really need some kind of way to extend the service and jam some 
>> arbitrary data on the server (be it data meant for a prim face, or 
>> just plain asset data), for this stuff to really take off.
>>
>> We need this extensible framework.  Anything less is just hacks and 
>> hurts everyone in the long run.
>>
>> -Jason
> 
> I'm sorry if my hacks are hurting you or anyone, personally I think they 
> are serving as good proofs of concept. If we implement SVG on a prim 
> using non-standard methods, by the time Qarl's patch is live it will 
> only take a few minutes to modify the code and submit a patch to JIRA 
> instead of saying "ok lets get started on this now".
> 
> (Feel free to CC this to the list if the personal reply was unintentional)
> 
> John
>