Jump to content

Bryon Ruxton

Resident
  • Posts

    48
  • Joined

  • Last visited

Everything posted by Bryon Ruxton

  1. A bounce protocol seems to me the first thing needed by any sensible communication system; whether it is about deliveries or instant messages. I made a(n) (unfortunately angry) JIRA about lack of such protocols a long time ago... after all this is basic 101 in electronic communication. I still can't believe that communication sent to someone, can go to "dev/null", due to a cap (fair enough) but without proper due bounce errors for failed delivery? Thinking about it makes me bang my head again...
  2. During the voice meeting, Oz mentioned: "For performance reasons, there's no good way to make that part of the code respect privacy settings." So keeping it simple does not seem to an option... Which led me to suggest two "opt-in based" possible alternatives.
  3. This just made my day: Lithium sucks. But that's okay. Because your framework sucks, too. http://www.slideshare.net/nateabele/lithium-the-framework-for-people-who-hate-frameworks
  4. I certainly don't want to be in a position to have to roll back to a smaller number Fair enough. In that case, I'd just say: "Make it 35!", if I were your boss...
  5. RE: "I’ll put a qualifier on the group limits increase, however, and state that if we see a decrease in performance (i.e., more lag), then we may decide to roll back to the 25 limit again." FJ, you puzzle me there. Is that a reflection of the American culture of all or nothing? How about just giving us 30 for now, and not having the risk of roll back? I can't imagine for you to be able to roll back like that, and ask people to kill groups once they have more than 25. Unless I am missing something in your reasoning, the possibility of roll back seems messy and a nightmare to handle on both sides. Thanks
  6. Stemfax, You actually agree. Getting rid of the setting as indicated actually means "IM to Email should always be the option". That is since the communication framework was half baked, with a disregard for carrying the communication though reliably at all times. The only need for such a setting would be if, and only if, IMs would bounce back to the sender. Basically the whole design is lame and inconsiderate of the most basic necessities. @Torley, So do I. The worse part of the current system is that it never says if the message didn't reach its destination, should it be the case. Who ever decided that this was ok should be shot. (Virtually speaking of course )
  7. Torley, that toogle is a disgrace, considering the IM cap exist. This whole policy is purely unethical and irresponsible. Please get rid of it. https://jira.secondlife.com/browse/VWR-7866
  8. All LL ads served by Double Click are pointing to http://secondlife.com/ including the "Find us on Facebook", "Linden Homes etc" and "Advertise on Xstreet" banners. PS: I find those ads slightly in conflict with the marketplace service you provide... yet I'd tolerate having them there until you offer third party ads. Past that, might be unethical just as google's bids on its own ad system is see a valid conflict of interest: http://www.theregister.co.uk/2010/08/18/google_adwords_house_ads_conflict_of_interest/ Please be mindful of that as you plan third party advertising on the marketplace. But for now please at least point each banner to the right place. It goes back to the dashboard right now... Thanks
  9. We will change the default behaviour to show both the Display Name and the unique Username if the two names do not match. If they do match, we will show just one (Display Name). Residents can still change this behaviour in preferences.Jack, If I read correctly, and as per the current FAQs, you are not allowing spaces, dots or hyphen in the username? If correct, it would mean that you will not be giving the ability for someone to choose John Smith as his name to be converted into john.smith as username. I think that needs to happens (one space need to be allowed when entering a name which ressemble to "First Last" with the space converting to john.smith as username. (The additional problem if you don't allow dots to identify spaces as such, will be the inability to detect a match between the username "johnsmith" (without a dot) and the Display name "John Smith", because technically I dont' think you can figure out where the word split was past the FIRST Display Name change... In such circumstance and according to what you said a quoted here, "johnsmith" would be seen as NON-MATCH with the display name "John Smith", and show both which is not making too much sense... Therefore, I also strongly suggest for you to keep "First and Last names" as well in the signup as a legacy option. e.g. Blue Mars is currently giving an optional use of First and Last Names that can be changed, after choosing a unique username (which allows hyphens), and good options to deal with how your name should display afterwards... If Blue Mars is smart enough to accomodate and use that culture, why the hell would you repel it completely? Please keep it as well. That way you keep that Second Life cultural legacy open, and let people choose a username with no spaces or a first and last name format with a dot placed in the username. Whether the last name is a list of given names or self determined, I don't know, maybe both... but removing the cultural legacy of choosing a "first and last name" format completely would be criminal. Philip (Rodesale) said at SLCC that it was "cute" as I recall. It's not just to be qualified as cute and to be axed like that, it's a culture of 5+ years you are messing with... A culture that Blue Mars understood and implemented rather well as this window shows. For not having seen the future registration process clarified on this level, I would appreciate if you could give more details on that process and whether you will allow what I explained here. i.e. As a user I want to keep the ability to choose a username like john.smith that will also default as display name John Smith, just like current names and/or be given the ability to choose a Last name in the future as alternate option during registration.
×
×
  • Create New...