These are issues that are solved or are supposed to have been solved. If they aren't solved, move them back to the main client document.

Resending Logged Messages

Messages that are received while user is offline are stored on the server and delivered when user logs in as _message_private. The problem is, these are shown in the user window, because they're coming from one's own uni. I think that's bad..

I think they should either be sent by the real author of the message, or there should be an extra message class for this like _message_private_stored, so the client knows it should show the message somewhere else (most times I don't look into my user object because I don't expect important things there..). I prefer the first solution, because the message IS NOT of me, even if handled by my user in muve internally.

<lynX> The first variant makes sense semantically, only the message is not resent from the original source routingwise, so resending it is incorrect. The original source resides in _source_relay.

<Kuchn> wird _source_relay häufiger verwendet? macht es nicht vielleicht sogar sinn das irgendwie mit mmp zu bestimmen, damit man immer den tatsächlichen author einer nachricht und den versender... oder gar sowas wie der Received-Header in SMTP, wo der gesamte pfad eines pakets eingetragen wird? ach kein peil, just an idea.

1. Don't have an extra window for your UNI. Put the stuff into the Status window where a lot of important information arrives.
2. Keep a line or an area always visible for the latest outputs in Status. When something fundamental goes wrong, you don't want to print an error message on *every* window, so rather have an always visible place for it.

<Kuchn> nja.. ob mans im status fesnter mit allem anzeigt oder in einem mit dem eigenen user ist doch einerlei.. da find ich letzteres sogar besser weil man mit der zeit eh weiß wo was ist und nicht zuviel gemischt wird.

<lynX> mir geht's darum, dass wichtige dinge nicht zur seite geschoben werden wie irgendein raum

_nick_verbatim

Ich habe mir sagen lassen, da _nick case-insensitive ist, wird hier die richtige version übertragen. aber was ist dann, wenn man sich nen alias anlegt - hat der dann die richtige groß-/kleinschreibung? der wird - so wie ich das beobachtet hab - dann als _nick übertragen, statt in einer extra var (wie es eigentlich schöner wäre), während _nick_verbatim den original-nick beinhaltet weiterhin.

warum überhaupt ein extra _nick_verbatim? _nick könnt case-sensitive sein, wenn man tatsächlich kleinschreibung benötigt ists ein katzensprung in jeder sprache.. genaueres im nächsten absatz "aliases".

hier fiel mir allerdings was auf @el:

.
:_source	psyc://ve.symlynx.com/~el
:_target	psyc://levk-d9b9e1e6.pool.mediaways.net:62462

:_time_raw	1125164253
:_nick_target	kuchn
:_nick	el
:_nick_verbatim	0
_message_private
doof

.
:_source	psyc://ve.symlynx.com/~el
:_context	psyc://ve.symlynx.com/@psyc

:_time_raw	1125164261
:_nick	el
:_nick_verbatim	el
:_nick_place	PSYC
_message_public
viel erfolg, bis morgen

man beachte _nick_verbatim sowie _nick_place.. was soll das?

 _nick_place ist der Kurzname des Raumes.

darauf wäre ich nie gekommen (ok gebs zu- schlecht formuliert -man sieht ja auch an der mc dass letzteres ne nachricht im raum ist.. garnicht dran gedacht) .. mich wundert nur, dass _nick_verbatim im raum richtig gesetzt ist, bei der privaten nachricht auf '0' gesetzt ist!?

<lynX> null ist eindeutig ein bug. bitte jagen gehen. und warum _nick nicht den richtigen case enthalten möge, frage ich mich auch!

<eL> es wäre hilfreich ein paar mehr infos zu den dumps zu haben. Welche konstellationen. psycmuve und du psyconaut? War ich das wirklich? D.h. meins war ein perlpsyc??

Listing of Friends / Buddy List / Roster

If your client is able to manage buddys, you should know how to query one's friendlist. This is done with /show. (muve's net/jabber has some kind of api for that, which should be unified with the psyc interface) TODO

<lynX> Superceded by _request_do_list_peers.

<lynX> Yeah could very well be that our XMPP client access implements some things more than the psyc client interface does.. We need to move those parts of code into a common net/client.c and use templates for the protocol syntaxes..

Sending messages to oneself

When sending messages as newbie, client gets back an _error_necessary_registration. But when this message is for yourself, you first get a _message_echo_private, which is without _nick and the other vars, a _warning_unable_reply and a _message_private (with _nick = UNL). it is expectable, but not very nice.. maybe some methods should be filtered out with warnings (like _warning_useless_thing ;). I think the same would happen without the _warning_unable_reply when doing this as registered user, but this shall be mentioned extra because this is at the moment the only case where a newbie is able to send private messages.. but maybe this isn't incorrect because only the routing of _message_private is affected of the newbie-status?!

Newbie Msgs

Mir fällt gerade noch was anderes auf.. Als Newbie kann man trotz _warning_unable_reply Nachrichten verschicken.. zumindest über natives PSYC. Also entweder sollte das auch verboten werden, oder aber es sollte auf die Warnmeldung verzichtet werden (ich nehme an ersteres wäre sinnvoller).

Die UNI versucht es Dir zu verbieten, wenn Du die UNI aber umgehst. Tja, was soll sie machen. Dich bestenfalls nerven. ;)

_status_person

_status_person_absent ist ja ganz sinnvoll, wenn man nachrichten an jemanden verschickt und der empfänger abwesend ist, finde ich. aber _status_person_present.. ist das nicht bandbreitenverschwendung, wenn man das immer wieder bekommt? man kann ja eh durch _message_echo_private sehen, dass der empfänger die nachricht bekommen hat. oder wie/wozu ist das gedacht?

<lynX> das sollte nicht an psyc clients gehen.. nicht ohne state :) ist für clients und protokolle gedacht, die eine statuszeile haben.

Transmitting to remote places thru UNI

when i tried to enter @heise on ve.symlynx from beta.ve., following occured: remote join heise from beta dump and when i tried to do it over _request_execute, it was unanswered.

<lynX> apparently the message was delivered to the local place/heise rather than the remote one. looks like a bug.

same bug: remote messages are echoed by the local room.. Remote msg dump

... I think this has been fixed in the last few months. Correct?

wrong "buffered" or so..

when you send a message to a place which causes an exception there, the text you've sent comes back in a wrong context. it's appended to the next _message_echo_public (maybe also other types? dunno).. i'll append a dump (as you see, the room's dead, i also get no answer to my _request_leave, which causes, if not handled by client, that you're "locked" in the room).

place exception dump with buffer failure

<lynX> oh yes, the buffer effect is very very amazing. as if it consciously saved the text until there is no more exception. very nice gesture indeed. TODO

(while the other problem is solved: exceptions are no longer output on raw sockets)