[Adium-devl] Solving, once and for all, problems with contact list ordering and grouping and aliases

[Dan]

Um, just a peanut gallery / user opin, hoping for a "bigger" solution...

...It's nice to send what you can back to the various services.  But 
Adium has become *more* than the sum of the individual services' 
groupings.  Because of that, just using their "protocols" will 
probably never be a complete solution.

Going beyond the current grouping mess, it kindof bugs me that Adium 
looses not only the grouping/meta but all "context" when it's not 
connected to a service.  That means with no 'net connection, I can't 
even queue messages to be sent to people when they're next seen.  And 
even the log window doesn't look right.

I'm thinking as part of a "bigger" fix to the whole sync problem, it 
would be really helpful if Adium simply retained all this information 
*locally* permanently.  Then it could be more functional (to a point) 
when not connected to the 'net or various services.

Then support a remote user-settable site, accessable via http, ftp, 
afp, smb, .mac, etc -- whatever the user has available.  Keep it 
simple; something the user can set up with minimal/no infrastructure 
other than file sharing.  That way, I could, for example, have Adium 
sync'd across all four Macs here.  And it would still be sync'd with 
a laptop that I manually sync now and then.

FWIW,
- Dan.

At 4:49 AM -0800 03/10/2007, Colin Barrett wrote:
>The situation, right now, is horrible. Aliases and group ordering and 
>everything aren't synced, and some protocols (*cough*MSN*cough*) don't 
>even offer server side storage.
>
>Here's my solution:
>
>Sync all of this to a server on adiumx.com or adium.org or what not. 
>The twist, which makes this actually possible, is to store hashes on 
>the server. That way a client can easily interpret the server's 
>information and correlate it to a particular contact, but no sensitive 
>information is actually stored on the server. It might be possible to 
>even avoid a registration scheme, and have the entries in the database 
>be hashes of the UID of the account (e.g. AIM.mactigerz).
>
>Of course, the protocol would be open (more on my ideas for the 
>protocol itself later) and in theory any client could connect, but 
>we'd probably want to issue API keys or something, to identify 
>clients. I don't think any of us have a ton of experience developing a 
>web-based service/server, so this sounds like something we could 
>potentially get help from an outside contributor with. :)
>
>Thoughts?
>
>-Colin
>
>_______________________________________________
>Adium-devl mailing list
>Adium-devl at adiumx.com
>http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com


-- 
- Psychoceramic Emeritus; South Jersey, USA, Earth