[sldev] Roadmap: 1.19.0 Viewer

[Kamilion]

Replying to 3 messages (trimmed) here:

On Jan 10, 2008 6:13 AM, Argent Stonecutter <secret.argent at gmail.com> wrote:
> On 2008-01-10, at 02:23, Matthew Dowd wrote:
> > vi) One of the issues with the communicate window at the moment is
> > tab clutter. This results in the window taking up too much valuable
> > screen estate and IMs being overlooked since the flashing tab to
> > indicate a new message gets lost amongst all the other tabs! One
> > solution, I've proposed is to stack the tabs vertically (http://
> > jira.secondlife.com/browse/VWR-3265), which was generally well
> > received although it was suggested this should be optional (and
> > I've not had a chance to revisit this).
>
> I would have to patch the XUI to undo that... again... if that was done.
>
> I already patch the XUI every time I install SL to get the contacts
> tabs on the bottom, as in http://jira.secondlife.com/browse/VWR-1549.
> I still don't understand why they rejected that one, it's just nested
> tabs and not confusing at all.
>
> I also make them tear off. That works well _for me_ but without
> matching code changes I have to be careful what order I open windows
> in, because it's possible to get SL confused and try and render into
> a non-existent window, which crashes it.
>

----

On Jan 10, 2008 6:45 AM, Matthew Dowd <matthew.dowd at hotmail.co.uk> wrote:
> > From: secret.argent at gmail.com
> > Date: Thu, 10 Jan 2008 08:13:09 -0600
> > On 2008-01-10, at 02:23, Matthew Dowd wrote:
> >> vi) One of the issues with the communicate window at the moment is
> >> tab clutter. This results in the window taking up too much valuable
> >> screen estate and IMs being overlooked since the flashing tab to
> >> indicate a new message gets lost amongst all the other tabs! One
> >> solution, I've proposed is to stack the tabs vertically (http://
> >> jira.secondlife.com/browse/VWR-3265), which was generally well
> >> received although it was suggested this should be optional (and
> >> I've not had a chance to revisit this).
> >
> > I would have to patch the XUI to undo that... again... if that was done.
>
> No - that was were this suggestion has stalled - probably worth doing but only if the user can
> configure whether to have the IM tabs vertical or horizontal, so you wouldn't need an unpatch,
> you'd just need to make sure the appropriate checkbox was ticked or unticked (or whatever).
>
> Matthew

Configuration is good. I like the vertical stacks, but it's not
something for everyone. I've used a couple IRC clients that can expose
a server/channel tree in the same way, but they always have a toggle
for the mirc style tabs that SL already uses.

However:
Upon reading both of these JIRA reports, I realized something.
Would this not be much less cluttered if you took VWR-1549's
Screenshot-2 as a base, and simply split the tabs logically?
Groups tab and group IMs along the upper band
Near Me, Friends tab and normal IMs along the bottom band?

That would result in a second checkbox:
[X] Sort Chat by Message Type
_________________________________________________
On Jan 10, 2008 8:04 AM, Hamncheese <me at hamncheeseomlet.com> wrote:
> Actually XMPP (jabber) has a different format than most other non-XMPP IM
> clients. Make that firstname.lastname at someserver.com/resource and you would
> be correct  Which lends it self real well to signing into groups because
> resource could be the group token that you are signed into.
> ----- Original Message -----
> > Your Jabber ID in SL would be something like
> > Firstname.Lastname at jabber.secondlife.com, and whether that would hook
> > into the rest of the jabber scheme or not is probably outside the  scope
> > of this list... AFAIK gmail still doesn't, for example.

Gmail and Google talk are federated for IM only, not gtalk's SIP/RTP
VoIP over XMPP presence.
Resources would indeed be able to join IM and group conversations with
a participants list on the jabber side.

The XMPP protocol, you can consider it a generic message passing
through ID architecture.
Mainly, XMPP controls presence. A lookup table of endpoints. What
messages that pass are layered on in message containers on top of that
lookup table. Normally, a jabber server is running at least three
resources: Presence, Lookup, and Instant Text Messaging. Everything
else that has been layered on, such as file transfer, per-user
thumbnail pictures, VoIP, Group Messaging, Group control, has been
tacked on top of XMPP's presence and lookup services. They are
normally exposed by resources, or in some cases, can be controlled
over the Instant Text Messaging message types.

The dead simple way of deploying such a large group IM change such as
moving over to XMPP, would be to simply duplicate some of the existing
behavior of the friends tab --
[X] Group Chat
[X] __ Notify when Activity
[X] Can see my online status

Group chat toggles joining the session on login, Notify on activity
will only open the window when a session occurs, and the third will
not show you as online in the group roster.

Livejournal has a very active XMPP/Jabber system running.
Check out http://www.danga.com/djabberd/
Quote:
Consider DJabberd the mod_perl/qpsmtpd/Perlbal/Plagger of the XMPP
world. Everything is a plugin. The framework lets you override the
behavior of:

    * Authentication
    * Authorization
    * Roster Storage
    * Automatic roster population
    * Presence lookup
    * Message delivery
    * Internode communication
    * ...
    * everything else



-- Kamilion Schnook