$Id: CHANGESTODO,v 1.1650 2008/12/30 12:35:00 lynx Exp $ vim:nosmarttab
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
This file contains TODO and CHANGES (at EOF) rolled into one.
Essentially: whenever you fix something, move that line to the end of file.
- marks bugs & fixes, + marks new features, ? marks issues, * marks big stuff
________________________________________________________________________
== currently being inspected ===========================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- when a jabber clients disconnects and reconnects quickly, before the sane
quit delay has operated, it will not be given other people's presence again.
? marenz says, remote topic isn't working
http://about.psyc.eu/?title=Talk:Bug_Report&curid=1506&diff=10174&oldid=10173
+ show chiffre in /tcp
- remote IRC place does not send names listing on /join
- remote IRC /part shows no reaction at first attempt
+++ not limited to IRC!! thx marenz
- /set multiplace should be ignored for rich accesses
- XMPP: first reply to a stranger's remote psyc message did not show up in psi
? would you prefer psyced to store hashed passwords by default ?
- IRC shows "*** k kindly asks for your friendship." for remote
friendship requests. eh! where's the uniform!?
- /m freenode:symlynx hey
Sorry, _message_private is not supported by the IRC gateway.
huh? wasn't that once the point to make them? debug...
- tjgillies ponders: connecting to psyced.org with psi pops up a
profile window everytime
- tjgillies: meebo doesn't let you put * in MUC name
AFAIK the xmpp: uri does not forbid * from the URI RFC thus
meebo should be incorrect here. we'll have to talk to them..
- google talk also makes funny errors, maybe because of the '*'
/me asks: you see me?
/me asks: you see me?
- minor paranoia thing:
- cvs-move archetype.pl out of the sandbox
- change the require in psyconf to point to the new path
! profiles.pl and its Makefile aren't a real threat, we don't expect
anyone to run them, they are for developers only.
- spam by unregistered users: limit unregistered users to 1 per minute for now?
or force them to do web-based registration? or even.. trustee-based?
it's the real thing.....!
? archetype.gen & other places: current privilege model sux.
qAide(), qOwner(), boss(source), v("topic-user")
.. how does this fit with confctrl, _duty and qAllowExternal?
.. and in some cases you just want to check for isMember
- filter strangers is off by default, but we still seem to get a warning
+ we should put _trustee into messages to strangers, so we can talk with
people who we have friends in common with, by default. *TRUST*
? in gui clients this could be a menu option in a buddy list:
"contact a common friend" .. and of course when /surf'ing
? is it a good idea to use SIGS in user:cmd, too? not sure!!
- experimental rename fails sometimes:
Attempt to rename to existing object '~nautilutz'
possible fix: separate user identity from user access interface (see below)
- REGISTERED_USERS_ONLY does not behave properly on IRC port
(see also NO_NEWBIES ... clean up and rename?)
- still UTF8 problems, once a day typically:
[Thu Jul 31 22:10:57 2008] C:xmpp:somewhere "*regexp: bad UTF-8 data
" "/me würde auf '96 tippen
? tg reports inconsistent display of availability states in friend contextes
so far unable to reproduce
________________________________________________________________________
== NEXT RELEASE ========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
+ before doing an announced new release, psyced should accept old psyc
syntax but send new psyc syntax by default!
? support tls multiplexing on all suitable ports
________________________________________________________________________
== psyced 1.0 ==========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
INVITE ISSUES
- remote /invite is shown without uniform, just #nick_place
remote invite thus doesn't work for ircers..
beta's lynx invites psyc://psyced.org/~gynx into TEST.
gynx thinks it has to join #TEST on psyced.org, not on beta.
only +follow behaves correctly, but clients don't use that
- invites von remote für remote (goodadvice/~fippo an psyced/~chr nach @psyc)
werden nicht als lokal aufgelöst
ein follow führt dazu, dass die person im nichts landet...
someplace @> «psyc://goodadvice.pages.de/~fippo» fippo lädt Dich nach psyc://psyced.org/@elsewhere ein.
/f
brain <>
? invite-only places: does a double /invite uninvite people!?
(and is it a feature or a bug?)
- ircinvite() crashes when given wrong arguments
+ _notice_invitation with a _tag could allow other entities than the
explicitly invited one to follow suit
- /invite's can get lost because they are transmitted by UDP unless
there is a circuit already (should it be a _request!?)
- /invite should do remote echo like _message_private, not local
REMOVE NICKNAMES FROM PROTOCOL
+ remote uniforms could be passed around in the psyced as parse_uniform
arrays rather than as strings. this opens up the possibility to have
a stringprepped+lowercased version of the uniform for comparisons.
also this could be used as a key in a general hash of known remote objects
avoiding unnecessary parsing and ensuring uniqueness of such arrays.
doesn't that also mean we can compare remote users simply by comparing the
array pointers? and if so, does it mean we don't have to differentiate
between objects and arrays when comparing identity of two entities?
in fact - we already don't need to do that for strings either - thus
if we want to introduce arrays instead of strings we must ensure we can
compare them without an extra objectp() distinction.
+ this also allows us to REMOVE ALL _nick VARS and extract nick from uniforms
+ support addressing of uniform portions by psyctext entity syntax
(how does psyctext state support fit into that picture?)
PRESENCE STATUS
+ all _status_person need to be upgraded to _status_presence with
availability etc.
- _status_person_present appears as a chat msg for local jabber/server users.
probably best to do the new _status_presence thing and fix this en passant
- presence rewrite problem mit lastaway
12:48 !ve.symlynx.com Du sagst noonee: hmm
12:48 !ve.symlynx.com Anwesend: noonee ist immer noch sichtlich verwirrt....
12:48 !ve.symlynx.com Du sagst noonee: oook
12:48 !ve.symlynx.com Anwesend: noonee ist immer noch sichtlich verwirrt....
- dexter fragt Dich: So, why does your client tell me "lynx is psyced!... " every time I send a message?
net/jabber/user should be filtering _status_person_present
- da scheint ein template zu fehlen für irgendeine neue oder alte presence msg:
net/jabber/user#whojarr oops is a roving piker.
* see also various PRESENCE boxes
DECENTRALIZED STATE / PERSISTENT CONTEXT SLAVES
- do not send revision with every cast
+ we could use better integration of availability
because right now CACHE_PRESENCE doesn't work
+ the next step after CACHE_PRESENCE: don't cache it in the end users,
cache it in the cslaves - also do so for _state in general so we can
keep profile data (PHOTOS!) of people in their respective cslaves
rather than have them multiplied all over the local usership.
yes, we need those photos (miniatures at least) for html friend lists
see PROFILES for all the issues that depend on this one being fixed first.
- w("_warning_usage_set_language",
"Mittels \"/set language de\" kann zur deutschen Sprache gewechselt werden.");
cmdvars = ([ "_command_character" : cmdchar ]) ); ?
cmdw() - makro für meldungen mit automatischem cmdvars?
... oder lieber eine saubere state implementierung, weswegen der cmdchar
im state abgelegt ist, und jedes template darauf zugreifen darf?
"Usage: [_target->_character_command]command "
kann man ja erstmal im psyctext für _target supporten, remote state
(_source, _context) kommt später.. see http://about.psyc.eu/Talk:Entity
+ fix up packet ids for apps that need to weed out dupes
packet recovery is a whole different pair of shoes, not considered now
but related to the big DECENTRALIZED STATE issue rather
? fippo suggests that keeping member lists in sync by revisions
is useful even when we have packet ids in place.. some places it's okay
to lose packets if at least the member lists are in sync
GENERIC CONTEXT SUBSCRIBE / PRESENCE FOR ALL
+ krasser rewrite und fusion von raumanwesenheit und buddylists mittels
generischer presence.. siehe auch http://about.psyc.eu/presence und..
schwer zu glauben, wir haben heute festgestellt, dass wir subscribe,
enter leave und friends nicht brauchen weil es alles sonderfälle von
asymmetrischer presence sind. also wenn der raum die presence eines
users abonniert kommt das aufs selbe raus wie ein autojoin - nur feiner
aufgedröselt - und wenn ein user den raum abonniert, dann kriegt er mit
was mit dem raum passiert.. das is dann zwar eher action als presence
aber wegetechnisch dasselbe. subscription states und contexte sind also
die antwort zur modellierung aller kommunikationsformen in einem chat.
see also http://about.psyc.eu/subscription
+ FRIEND_ECHO ... send echo for /fr type commands from recipient
not from own UNI (see #ifdef FRIEND_ECHO)
... or just rewrite it all into context subscription!!
________________________________________________________________________
== TOP DELEGATES for 1.0 ===============================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- bartman sagt: psyconf erkennt keine absoluten pfade bei _path_PEM_key und _path_PEM_certificate
- world/static/index.html should be generated to contain applet port
- fix member list in applet
* see also APPLET, ANNOUNCEMENT, JABBER, FILE TRANSFER
- el: und irc bekommt keinen join fuer den raum
welche? bei newsräumen ist das richtig so
.. obwohl? überhaupt keine bestätigung!?
+ login message that tells you about amount of pending/offered friendships etc.
+ Fix the /surf HTML code, see http://about.psyc.eu/Talk:Style
- /surf auf fippos async umstellen
- /surf von xmpp: klappt nicht mehr, es fehlt der _tag
(schade weil es ja sogar die bilderschen zeigte.. ;))
- "Store Changes" in scratchpad using https: doesn't always work (even tho
it is a GET, not a POST) - maybe this affects other uses of https as well?
(currently disabled)
- registering target xmpp:lynx@ve.example.com isn't working. psyced
reconnects by xmpp, then switches to psyc every time
- gino75 schließt mit Dir Freundschaft.
why does it show account name instead of alias? (gmail)
- flood control over psyc - context-based? parser-based?
- message size control? how does this interact with trust?
? should _silent rooms say hello when entered manually?
an irc client doesn't get _any_ response. an irc client could in fact
receive any sort of join notice even on subscribed entry.
since it is legal on irc to request a topic of a place you aren't on,
we can simply send topic (332) for subscribed places.
then again some topics are too long, so maybe only on manual entry
- convert place:cmd's to SIGS where trivial
+ add _request_do for user:cmds where trivial
+ in the spirit of http://en.wikipedia.org/wiki/Test-driven_development
insert plenty of ASSERT() checks to make sure every software module
does what it should, and only that. See also "See also" and
http://en.wikipedia.org/wiki/Test-driven_development#External_links
http://en.wikipedia.org/wiki/Agile_software_development
inspired by http://programm.froscon.org/2007/events/42.de.html
- when rootMsg receives a message for a uniform that was probably intended
to be different (like psyc://psyced/x instead of psyc://psyced/@x) we
should generate a Malformed uniform warning
- when rootMsg receives unexpected messages we should return errors as
they are helpful to client coders who just got something wrong.
? rootMsg should understand _request_version
- i was just testing for irc.. but anyhow, when a user tries to deliver
something to psyc://beta.ve.symlynx.com/~lynx@psyc it should result
in some decent error from beta, not try to resolve 'psyc' as a hostname
? /eject command that throws everyone out of a place - like a reload or
restart used to do in the past. just in case you need to fix your
member data...?
- the /kick sendmsg doesn't show up at the kickee's (makes it nastier
than planned)
+ change of nick/identity / account deletion & transfer / redirection services
... we have forwarding by /set id now. it's a start.
+ /set redirect temp|perm in usercmd.i for users
- place redirection doesn't work for ircII: client still thinks i am in the
first room while i get messages from the second room. when i type stuff
to the first room, it doesn't even forward to the second.
________________________________________________________________________
== MINOR DELEGATES =====================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- psyced generates tags for /enter operations. since these weren't generated
by a client they may confuse a client. fippo thinks these _tag and _tag_reply
should be removed from the messages before the get forwarded to clients.
- html code for manual pages should render better on mozilla (indenting error)
(fixed on access.fmt - TODO on rest). dabei muss der in die zeile
genommen werden und mit abgeschlossen. automatisierbar!??
+ the old html code needs to be replaced by the kind that can be styled by css
+ find a way to generate manual from wiki?
+ generate help pages tuned to the needs of the user?
(consider scheme, operator status and the like)
- move templates from source code into default/en/plain.textdb
.. maybe write an automation to do it? they're just too many!
run more mailcast gateways!! on psyced.org? or elsewhere?
- /log 9999999999 produces
Numeric overflow: 1410065407 *= 4
- for irc whois _groups should be output using RPL_WHOISCHANNELS
(groupsexpose)
- psyc/circuit:greet() reports all protocols w/out checking ports.h
- optimization: psyc/parse is resolving the incoming hostname for each single
message.. this is wrong. resolution is enough once per tcp link (unless
of course the other side is presenting us a new hostname..)
fip suggests to cache connected hosts in sAuthenticated()
and delete them again on connection shutdown.
? does spyc/* fix this?
- parse.i erlaubt es den begrüßungspunkt wegzulassen wenn man
stattdessen ne leerzeile liefert. aua -- egal, wir wechseln auf spyc
- /silence conversation doesn't filter /action
+ always requested by the channel inhabitants on traditional IRC:
private gatebots for one user only - transport style...
- /set color #000000 kind of 'fails' since hex2int("000000") is the
same as hex2int("red"): zero. return -1 for non-hex? pretty logical.
- history export doesn't show masquerade nicknames
in fact.. masquerade nicknames aren't shown in most output forms
especially not for remote users
but they should, everywhere except for irc maybe
- tg reports: the nick shows up like net/irc/user/#foo in IRC
+ install.sh sollte lieber mit bereits ausgepackten tars operieren
können damit man darin tweaken kann und install nochmal anwerfen kann
... geht bei psyclpc, aber nicht beim psyced
? generate psyced without cvs support if no cvs installed?
... bzw. git
WINDOWS DISTRIBUTION
? how can we compile SRV into erq.exe? do we care?
? which open source installer for win to use?
? what to do about psyconf.. include perl or re-implement psyconf for win?
________________________________________________________________________
== OTHER MAJOR TODOS ===================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
+ provide a tuning for ACTIVE server-side PING (keepalive) ?
see http://about.psyc.eu/Ping for explanations.
? 420 added place profiles for psyczilla! reorganize listDescription() ?
- warum wird eine mailto: uniform durch legal_name() gejagt?
/m mailto:kuchn@example.dre.am moin.
Filter: kuchn_kuchen_dre_am empfängt keine Nachrichten von Fremden.
Du sagst mailto:kuchn@example.dre.am: moin.
kuchn_kuchen_dre_am ist nicht registriert, wird daher nicht antworten können!
- restart mechanism is broken - doesn't save .o files in time etc
betrifft nur user (oder nur mich) .. räume sind aktuell
+ redo _flag_disable_info_session as other default of /set greeting auto
? apply more TAGGING (tagged callbacks also avoid the monster switches)
/lusers shows: There are 441 users on this server.
no, this is not a number from smtp spam links.
- either we keep an extra counter for people who are _really_ online
or we avoid summoning people just to hand them out a _notice_presence.
the latter makes sense really.
- also, offline users are never unloaded apparently, so the problem is
somewhere in the reset() or clean_up() procedure. we first need to
unload them, then we can look into not loading them in the first place
CIRCUITRY
- _request_circuit_shutdown isnt issued or doesnt arrive
or is the disconnected-detection buggy?
+ net/circuit:pushback TODO:
// alright. so this is where we want to do something
// differently, like remember that this host didn't work.
? another interesting aspect about circuits.. if you retry a lot, then
you don't give dyndns a chance to get updates through. psyced gets
stuck trying an old ip until retries are over. but shouldn't dyndns
work anyway? why is this happening? (happened for tjgillies on EC2)
- as long as people have dead host friends in their data, psyced keeps on
trying to connect those hosts. better _failure treatment is one side of
the medal, but muve should also be more aware of hosts it has already
given up hope about (and maybe wait for something more personal like a
_message to trigger a retry.. or downgrade the host to udp delivery).
? maybe disabling udp-for-notices wasnt a smart idea after all!?
it was supposed to make debug life easier, but maybe that's not true
? two approaches to address the issue:
? move parts of the ppl data structure into context masters,
then have a flag remember when a member induced a failure and
keep him quarantined until he is seen as being alive again
? simpler: keep the distribution tree intact, but the last
host with the repeatedly failing outgoing connection provides
occasional failure reports to all involved senders, then silently
drops things that were undeliverable (in the case of packet ids,
the broken recipient still has the possibility to recover the next day)
- Repeatedly unable to reach whatever.example.com in order to deliver a
_message_private to 0. Why does it say "0" here.. ouch.
? what to do when hosts talk faster then we resolve them?
see around _error_invalid_host_slow
TRUST1
- _request_circuit_trust needs to check some challenge, or it can be
tricked by replay. so for now only use it over safe networks!!
? generic SASL for xmpp, psyc and irc?
TRUST2
? TRUSTED_HOSTS are permitted to relay, this allows all users from that host to
relay.. not so cool.
+ the trust implementation needs to learn to distinguish host trust and
person trust, yet understand the interaction and develop maths for it
SCHEMES AND SERVICES
+ allow for icq: rather than xmpp:XXX@icq etc.
+ implement *.service.* and *.scheme.* etc according to
http://about.psyc.eu/Directory_Service - so that mailto: works for any server
+ move the .psyc.eu suffix into a #define
+ implement forward-to-mailto-when-offline as a generic forwarding feature
FOLLOW INVITES
+ /set follow all|friends|none
allow your friends to invite you (and make you follow) into a room
so that they can immediately start talking to a group of people like
in a cc: mail without them having to be physically present at first
+ then again, why not just let _trust decide if your friend is friend enough?
? AUTOFOLLOW by CHANNELS?
consider however, that once channels are available, you can always
create a subchannel of your self context, containing only the friends
you want to have a conversation with, and poof you can start talking!
- ok, x@y notation sollte mind. dots im host überprüfen,
wenn nicht sogar leading #
In BuHa fragt el_presidente: inseln?
In BuHa fragt el: schonmal /join #fluppdiwupp@ircnet versucht?
In BuHa fragt el: oder /join #buha@euirc ?
C:xmpp:ircnet · ircnet does not resolve
C:xmpp:euirc · euirc does not resolve
In BuHa fragt el_presidente: was soll da passieren?
- improve handling of "Minusport" outgoing stuff:
reject and handle _failures
? suspend flag on error? like this: when you receive errors, that a user or a
host could not be reached, then the castmsg'ing entity could flag this
candidate as 'suspended' or 'temporarily unreachable' - and automatically
change this status with the first sign of life from that entity or server.
this would save friendship status and room presence across downtimes.
? uni.c kümmert sich nicht um castmsg(), weswegen presence zurecht immer
zur UNI gehen, aber leider auch raumcasts. im falle von jabber UNRs
ist das sogar ein problem. und was ist, wenn zwei UNRs von derselben UNI
im raum sein wollen? liefern wir die UNR doch noch in einer var mit?
und wenn es um das eintragen in die members gehen, verwenden wir tatsächlich
mal die _location statt der UNI die im source steht?
- fehler im _echo von messages mit _action, da sollte 'lynX zuckt' stehen.
fritz ~> :zuckt
fritz: fritz zuckt.
active.c zeile 247.. müsste man da vars neu zusammensetzen mit
_nick_target usw? oder sollte einfach irgendwo vorher ein copy() hin?
das betrifft sowohl jabber als auch remote psyc
fippo: TAGGING koennte dieses problem bald loesen
wie denn? was würde reply() anders machen?
PRESENCE
- eigene mood & availability erscheinen nicht im showStatus
(description schon, aber das war's noch nicht)
- irc access receives _status_away notices for each message they send to a
local away user. shouldn't it be only one? nei asks if it could be a
regular irc away code.
- detach attach offline online etc. cmds undocumented as yet
- _request_status_person receives no availability, desc and mood
? dont send presence info to strangers
sollte nicht sein
man kann _request_status oder sowas senden, und kriegt antwort
? dont accept presence info from strangers
man kann eine passende _notice machen und wird sogar als friend gelistet
- persistent_presence does not store description and mood
gmail hat irgendwelche anderen probleme...
- heute nachmittag stand auf dem schirm:
oops schließt mit Dir Freundschaft.
TAV möchte mit Dir Freundschaft schließen.
bin mir ziemlich sicher, dass es keinen lokalen oops gibt.. es handelt sich
um eine fehlerhafte doppelte darstellung vom TAV alias ohne sein @gmail.com!?
einige stunden später:
Du bist mit oops bereits befreundet.
TAV möchte mit Dir Freundschaft schließen.
? mir scheint das passiert nicht mehr..
wenn "bereits befreundet" ausgegeben wird, geht auch ne textmeldung an
tav auf gmail raus. eine die es in jabberland nicht gibt. das wär okay
wenn wir keinen bug hätten.....
* also eigentlich sollte da ein "meinetwegen bist du subscribed" rausgehen
weshalb wir nur noch das display an unseren user unterdruecken muessten
hier ein ausschnitt aus der rawlog..
» S:xmpp:64.233.166.129:-26112
« C:xmpp:gmail.com
« C:xmpp:gmail.com
..man beachte, die newlines nach type='subscribed'/> wurden scheinbar
wirklich gesendet, aber vermutlich harmlos. dass gmail einen subscribe
abschickt für jemanden mit dem man schon längst befreundet ist, dass ist
wohl das problem. vermutlich ein dirty hack im umgang mit herkömmlichen
jabber servern welcher bei uns aber doofe effekte hat. was tun? genau
genommen müsste man errors zurückschicken, aber das wird die gmail-user
nicht glücklich stimmen.. sonst? einfach verwerfen? na gut
... hmm würde es reichen dafür ausserhalb des switch display=0 zu setzen
und nur im fall von PPL_NOTIFY_PENDING display=1 einzuschalten?
* man sollte wirklich mal von wem kompetentes auf gmail-seite den
subscription state checken lassen. ich vermute, die lassen
gaim-b0rkedness raus in die welt.
- ouch!! ganz schlimm.. es ist kein gmail-only problem!
wenn ich mit Alias: xmpp:symlynx@example.ccc.de = JYNX /friend mache kommt:
symlynx schließt mit Dir Freundschaft.
JYNX möchte mit Dir Freundschaft schließen.
immerhin funktioniert danach alles trotzdem.
das ist nen alias-problem das schon laenger besteht. genauso zeigt
net/irc manchmal noch nicks statt uniforms an.
- C:xmpp:jabber.ccc.de Invalid Packets Recieved nach:
nein, hatten wir noch nicht gemerkt
Recipient Is Unavailable
anscheinend wird dieser error nicht verarbeitet und löst einen runtime
fehler aus welcher auf dem jabber socket zum abort führt (warum ist ldmud
immernoch so doof runtime fehler auf sockets auszugeben!??) - leider ist
das entsprechende debug nachm reboot weg. der error sollte als
_failure_unavailable_recipient an den place durchgereicht werden, welcher
den teilnehmer dann kicken würde.
- is pop3 still working? i'm getting funny auth problem (hello async)
- fip: el's weggang wurde dem fippo auf dem lokalen server gemeldet
notiz: manchmal wird der weggang sowohl an den lokalen als auch
an den remote fip rausgecastet. soll aber nur an
remote fip.
interessanterweise passiert das nur beim weggang, nicht
beim ankommen. potentielle datenstruktur-korruption?
passiert uebrigens nicht nur beim weggang.
- falls /set entersilent off so erhalten bleibt, dokumentieren
PROGRAMMABLE USER IDENTIFICATIONS & MULTIPLE CLIENT INTERFACES
+ fippo insists on the uni/client split..
= separate user identity from user access interface
(and saga has been asking for years) .. read also 'person.gen' below
- this would probably also solve the issue with the ~nick object name plan
+ and it allows for multiple jabber resources, of course
? one day we could have a person.gen to create all sorts of user
objects from, but it sure is confusing that each of them still needs to
be able to call upon the various protocols.. this may either need a
seperation into user/client/access and person/identification objects, or
the needs for variation of person code is small enough that we can merge it
all together as we have done up to now, and customize it dynamically
using /set commands or web forms, which is itself a flexibility plus.
in this case a few ifs are probably better than rewriting everything for
optimized bytecode. if you want optimization you should write yourself
a UNI server in c++ anyway... ;)
? consider also what CONTEXT CHANNEL requirements the new identity has
WHITELISTING & BLACKLISTING on the SERVER TRUST WEB
+ enable the #ifdef such that dialback from new hosts is not automatically
replied to, but a _request_trust_manual is sent to the monitor.
see also http://about.psyc.eu/Talk:Encryption
? the admins have a new '/server trust' command to whitelist a host
+ just because a cert tells us the server is who he is doesn't mean we like him
+ manual whitelisting triggers a server-friendcast telling the network
of server friends, that a new server has been whitelisted ( _notice_trust )
+ these friendcasts can be shown in the respective @monitor places again
and either request manual interaction from the admin ( _request_adopt_trust )
or -depending on trust levels and admin settings- automatically whitelist
the host, too ( _info_adopt_trust )
+ manual ip blocking may also be server-friendcast, or maybe only when it was
effectively applied to an ip and threw somebody out, not the entire mask.
this uses the same methods as above, only with unfriendlier trust values.
+ again, this could cascade a blacklisting on other servers, too
+ the _info family should be used exclusively as a light form of _warn
when the server tells you about things that have happened automatically,
like an automatic blacklisting. _info_adopt_trust or something.
CHARSET
+ ensure UTF-8 at parsing time on all inputs so we can
a) remove the action limitation:
- when an umlaut appears in speakaction, then the entire line is not
successfully converted to target charset. very weird. current solution:
speakactions are not permitted to have utf8 chars.
b) no longer necessary if we ensure utf8 input:
? use the ldmud charset features to avoid illegal codes to be output to
telnet users.
? http://spaceboyz.net/scharset.html
rede gerade mit equinox darüber. die änderung von 011 ist durch.
vielleicht wechselt er ja von SCHARSET auf SET CHARSET
- CONSOLE_CHARSET remains an issue, because some debug outputs or runtime
errors will want to %O arbitrary data which will not be utf-8 compliant,
so it is still necessary that CONSOLE_CHARSET learns to be easy about it
== PSYC 1.0alpha =======================================================
THE BIG METHOD RENAME
- shouldn't all _tag_reply be renamed into the more generic _tag_relay ?
i mean.. pushback setting _tag_reply is semantically wrong whereas
setting _tag_relay makes sense. the MMP spec has abandoned _tag_reply
in favor of _tag_relay.
- methodennamen in japsyc wenigstens anpassen, selbst wenns nicht 100% liefe
? change psyc syntax for _message, move text into sth like _data or _text?
--> re-introduce _conversation ? yes! _message_behaviour is wrong
? v()storage-variablennamen global in psycige namen umbenennen
-> gut für _request_retrieve und _request_examine
schlecht für /set speakaction: wird es /set _action_speak !?
+ umwandlung der internen v("speakaction") etc in psyc-konforme
nomenklatur v("_action_speak") für einfache ausgabe an externe
clients aber auch an die textdb.
+ when thinking on how to optimize method names do also read through
all of the method parsers (msg() funcs, but also perlpsyc etc) and see which
methods should belong to common families in order to simplify parsing.
+ also make up a masterplan (on a wiki page first?) on how to name all the
#define's used in psyced, several of them going to get used in local.h etc.
even if psyced.ini makes this a little less dramatic. oh yes, the defines
should have the same names as the entries in psyced.ini if equivalent.
+ after /unsub and /unfriend we should also have /unset
COMPACT METHODS and KEYWORD INHERITANCE
nothing can be as fast as fixing the method inheritance at psyc parsing time.
since we have to patch compact methods into long methods anyway, we know all
the methods the muve can handle - so we can handle inheritance before passing
the mc on to the core. we just provide a register_methods() for special
non-standard services within muve, and provide a way for the applications to
find out what the original mc was (mostly needed for link forwarding to
clients). example:
lynx blurbs: also der parser kennt npp => _notice_person_present
lynx blurbs: sollte _notice_person_present_at_all oder npp_at_all eintreffen
lynx blurbs: merkt der parser, dass der muve code das nicht kennen wird
lynx blurbs: und korrigiert das herunter bis zum _notice_person_present
in fact.. we can even simplify all abbrev() calls into mere == comparisons
or switches in our muve code, because they will never be needed!
- when a _target does not comply to the rules, a message needs to be replied
to with an error. currently however, handling falls thru to rootMsg() like
this:
Circuit got _request_link to psyc://psyced.org/~White Spaced Username from psyc://10.20.30.40:-54925/
Circuit got _request_input to psyc://psyced.org/~White Spaced Username from psyc://10.20.30.40:-54925/: Hi
Circuit got _request_execute to psyc://psyced.org/~White Spaced Username from psyc://10.20.30.40:-54925/: QUIT
== PSYC 1.0 beta =======================================================
TYPE CHECKING AT PARSING TIME
- unless trustworthy > 4 all incoming vars should be checked for legal
content, like chars in actions etc.. or maybe switch over the varnames
and fix the obvious candidates.. if a method is non-standard (we will
be aware of this by 1.0) we should check each var mentioned in the body.
AUTOALIASES & ALIASES FOR PLACES
+ /set aliases auto
use temporary aliases for people in places,
keep them in [r]aliases mappings only, not in v("aliases")
copy them over only when the user decides to have private conversation
see also http://about.psyc.eu/nickspace
+ aliases for places
we have had requests for a way to shorten or at least maintain (bookmark)
addresses of remote rooms. i wonder if we should go ahead and code it in
the next obvious way (polluting the output of the /alias command even more)
or we should look at presence/subscribe integration first (where the
distinction of users and rooms becomes less relevant). see below:
PSYC protokoll verbessern, dass implementationen einfach sein können:
+ die lookup_identification queue in place/basic ist vermutlich nicht
notwendig, da (a) clients den zutritt zu einem raum von ihrer UNI
vermitteln lassen können und (b) scripte ihre informationen für einen
raum sowieso von der UNI relayen lassen können.. egal ob die UNI eine
person oder ein $service ist. wir sollten das protokoll also in dieser
hinsicht aufstocken, damit man nicht last-minute herausfinden muss,
wer wer ist, was den raumcode brutal komplexer macht.
problem dabei im falle (a) ist das verfluchte NAT, weswegen deine schwester
sich als du ausgeben kann. aus diesem grund muss die UNL für jeden empfänger
einen authentifizierungszusatz haben - das kann brachial der (outgoing)
peerport sein, wobei der aber jederzeit auch wegfliegen kann, oder
ein random erzeugter string. dieser wird von der UNI an den jeweiligen
empfänger übermittelt, damit der ihn kontrollieren kann. idealerweise
sollte man eine protokollsyntax finden, die gleichzeitig auch die jetzigen
_tags beim _enter bedienen, auch wenn sie eine semantisch ein wenig
verschiedene aufgabe erfüllen. -lynX 2005
anmerkung, diese auth-zusätze können einen digest-schutz enthalten: die UNI
teilt dem empfänger ein shared secret mit, welches der client erzeugt hat.
der shared secret kann selbst gesichert sein durch mehrere shared secrets
zwischen client und UNI sowie UNI und empfänger. shared secret verwendet man
zusammen mit MD5 oder SHA1, aber das ist wohl klar. und natürlich kann man
alles das auch gleich so realisieren, dass es mit public key encryption geht,
statt mit shared secrets in digests. digests sind lediglich handlicher,
aber sie würden die tatsächlichen inhalte der nachricht nicht vor mitlesenden
schützen.
? kann man die latenzeffekte von DNS auch besser berücksichtigen, und
dadurch die queues in net/circuit vereinfachen? unwahrscheinlich, aber
man könnte nochmal seinen grips drauf ansetzen.
HISTORY
+ add timestamp search to lastlog.c, add timestamp-based /history and /log
commands, maybe remove v("new") code. then again, it's quite efficient.
see person.h for details.
+ allo fragt: lynx: what about history expiring?
+ allo sagt: yeah, and then a /history since yyyy-mm-dd hh:mm feature ;)
+ allo sagt: and a backlog_num_days feature instead of num lines
- /history erlaubt nicht nach headlines zu greppen (news)
________________________________________________________________________
== JABBER S2S ISSUES ===================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- /x ALIAS aka xmpp:example@gmail.com results in
"[_nick_target]" ist nicht erreichbar.
example ist online + man hat friend status.
- "/i user@host" doesn't work for PSYC hosts. it gets rendered by
net/jabber into jabber-only code, but is later sent over psyc.
to fix this we need to do the queuing before the jabber code
gets its hands on it?
? http://www.xmpp.org/rfcs/rfc3921.html#substates
? _nick_local and coolname are shown, but cannot be identified
localMUC:
- MUC member list may be incorrect after psyced server restart..
we should probably castmsg all local leaves at shutdown
- when entering places from XMPP-S2S own id appears both
as "resource" and as uniform.
unscalable sagt: der fehler ist beim echo place enter und nur da
- when sending a "whisper" to a nick in a MUC we reply with an error
code 503 with . didn't we have something to say in there?
(gaim shows an empty box)
+ add /whisper command and real whispering in net/place/basic. (rcpt gets
_message_private_whisper, castmsg sees _message_public_whisper.. user.c
then has to filter that out when _nick_target is himself)
this should make users of jabberMUC culture happy.
- joining a psyc channel from XMPP-S2S with different handle (nick) is
still causing problems
? M1: apparently something in psyced's MUC implementation is making mcabber crash :(
remoteMUC:
- whispering in remote MUCs:
xmpp:psyc@conference.jabber.org sagt Dir: test
would be nice to see the nickname at least.. ;)
- (xmpp:jdev@conference.jabber.org/Light Lan) <-- nicknames with spaces
- When conference.jabber.org is down there is no error report about it at all
- fake any sort of showMembers() for remote MUCs...?
or actually implement it? looks so stupid on telnet when typing
... then again, telnet is the only protocol that could use that.. scrapped
- "asks" kommt blöd.. entweder visiblespeakaction immer, oder gar
nicht (implement visiblespeakaction in net/jabber)
- ausserdem wird kein asks erzeugt wenn jabberisten fragen stellen
- wenn man 5269 antelnettet und garbage reinkippt.. dann sagt psyced nix und timeoutet
sollte er nicht sowas hier senden?
- xmlquote vars at psyctext rendering time instead of guessing which
vars to quote in mixin_render:msg()
- properly inspect muc error codes instead of generating
_failure_place_enter_XMPP "jabberish reasons"
________________________________________________________________________
== JABBER CLIENT ISSUES (...experimental is justified...) ==============
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- v("place") isn't automatically set when actively joining a chat
- the /me command ist not properly treated
- incoming friend requests from lastlog (in absence) are not delivered!
- incoming xmpp:u@h and outgoing u@h profile data isn't properly merged
also 'user without @host' seems to produce funny fx
- moving people around in roster groups is not stored
- xx cannot handle friendships yet shouldn't be a
- authing an unregistered user should not be permitted
? der eigentliche join kommt mit kaputtem tag
- elmex: fippo: psyced.org failt soweit ichs seh bei mir alle tests bis auf den IQ auth test.
... Net::XMPP2 installieren und damit den muve testen?
-
elmex: der error muss aussen in den iq error
- elmex: ausserdem geht das unregister wohl net richtig, denn
beim registrieren bekomme ich halt den conflict da.
- elmex: nichtmal messages schicken geht richtig :)
ich schicke: von testxmpp2@example.org/x und es kommt als testxmpp2@example.org an, is das richtig?
elmex: fippo: ich geb zu, rfc 3920 is nicht sehr deutlich was das from attribut angeht bei messages vom client zum server
elmex: aber http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-03.html#stanzas-attributes
elmex: sagt das man die volle JID als from attribut nehmen soll
send<< testxmpp2@example.org/x
10Just a test
test body
recv>> 2nd_testxmpp2@example.org/x
test body
- elmex: und ich setze type auf 'headline' und es kommt type 'chat' an
elmex: 2 bugs in einer message: type und subject werden gekillt
- elmex: fippo: discos an resourcen gehen auch nicht?
send<< 2nd_testxmpp@beta.ve.example.com/x
10
elmex: auf den disco bekomme ich 0 antwort
elmex: testxmpp@beta.ve.example.com/x bekommt den nichtmal
fiPP: wir mögen resourcen überhaupt nicht
fiPP: das wird alles gefiltert und vom server beantwortet
- elmex: fippo: von subscription prozedur brauch ich garnicht anfangen oder?
- elmex: disco geht auch nicht
fiPP: dass wir auf iq teilweise mit message antworten ist nen uralter bug
end<< 2nd_testxmpp@beta.ve.example.com/x
10
recv>> 2nd_testxmpp@beta.ve.example.com/x
recv>> 2nd_testxmpp@beta.ve.example.com/x
- autojoin() is disabled, so jabber clients never get to enter newsfeed
places. no news is bad news sometimes.
maybe we should simply suppress all output of autojoins by maintaining
an extra jabber-only list of "actively entered" muc places, then have
all other contexts output as server messages (newsfeeds, rarely used
chatrooms). the user can then decide to enter the context "actively"
whenever he intends to speak on it, or simply wants a seperate tab
or window for it. this is treating jabber clients a bit like gui tools
or webchats.. but.. so what. [ other approaches could include some abuse
or multiplexing of pubsub with muc protocols to handle all aspects of
psyc contexts, but that would still need such a jabber-only context
list, so it's a superset or later feature of this. if i'm not confused
pubsub protocol would merely serve to integrate the /subscribe command
better into the jabber ui experience, and provide a correcter display
vehicle for messages than server notices.. right? --lynX ]
_request_list_item in person.c is a placebo. it would tell clients which
places are known and possibly have them autojoin. this may not follow the
psyc model much, but it's better than nothing at all. maybe there's also
some protocol for clients to store which places are to be autojoined -
which would be the complicated way to do subscriptions. still autojoin
doesn't act the right way in all situations, so it's not enough.
hey wait.. there is jabber:iq:private code in jabber/user.c that
should do just that - it even provides autojoin='1' but i haven't
seen a single client honor that. maybe just some bugfixing necessary?
- iChat sends /me with a newline after and before the /me
.. it doesn't get seen as /me, but it doesn't get output either!?
? neulich wurde 'stanly' beim runterfahren von psi nicht aus dem MUC genommen.
als er miranda hochfuhr war er bei uns immernoch im MUC und bekam die
MUC meldungen. ob der fehler bei psi oder uns liegt, k.A.
? wenn wir psyc die eintragung von beliebigen weiteren identifications und
locations pro user beibringen, könnte man dann diesen user via jabber
transports in seine im-logins einloggen?
- aimgate sendeoptimierung auf #if 0
? ouch.. wir haben immernoch psyctext fehler:
net/jabber/user#example
- niekie entered #welcome both by telnet and xmpp. when the telnet
logged out, his xmpp client thought he had left the muc also.
ok, so the psyced did correctly handle both your identities.. only that your client interpreted the other you leaving as you leaving.. kind of logical
i will ask fippo if the xmpp-you can be assigned the full xmpp url as a nickname mucwise, than it shouldnt collide.. i noticed it pretends you being local, which is a lie
- wenn ein jabber client ohne zu gruessen verschwindet, wird der user.c
erst gequittet beim versuch mit ihm zu reden (evtl tage spaeter
erscheint er also immernoch online)
+ In welcome spricht mb: is there a way to turn off the welcome messages everytime someone gets connected to psyc, it is a bit irritating when you use clients like ichat who do not filter those messages into a seperate channel
-
- wenn man members eines (lokalen) raumes anklickt, geht ein query nach
#raum@host/user auf. was dort getippt wird kommt nirgendwo an, und
man erhält auch keine fehlermeldung...!
+ lustige bildchen unter: http://public.tobij.de/res/jbugs/
die bilder sind lustigerweise so benannt, dass sie, wenn man sie
normal alphabetisch sortiert, in chronologischer reihenfolge
erscheinen. in der dirlist werden sie das per default, jippie.
da erkennt man, dass vchrizz sich mit miranda (weiß nicht ob man das
erkennt, man sagte mir, es sei miranda) auf einen psycmuve als
jabberheimatserver connected, dann einen remoteraum (psyc auf brain)
betritt und da in den raumnachrichten keine nicks bekommt.
die user im raum bekommen allerdings seine nachrichten nicht, und es
sieht für die anderen user so aus, als sei er nicht da.
eben grade hat er es irgendwie geschafft zu joinen und mit uns zu
reden.
oh, unsere nicks sieht er jetzt auch. (letztes bild)
dafür ist im pseudojabberspace irgendein wesen namens #0 aufgeteilt,
dass auch exceptions produziert wenn man es aus der kontaktliste
löscht:
22:17 * nei sagt: .22:16:17. <@vchrizz> 13.01.2006 22:15:30 irc.onetrix.net:
EXCEPTION at line 179 of drivers/ldmud/library/library.c
(/net/library.i) in object drivers/ldmud/library/library:
22:17 * nei sagt: .22:16:17. <@vchrizz> Illegal file to load:
'net/jabber/user#0'.
22:17 * nei sagt: .22:16:49. <@vchrizz> hab den user #0 aus meiner
kontaktliste gelöscht
- wenn man beim registrierungsformular im jabberclient lange braucht um
name und emailadresse einzugeben timeoutet die verbindung: gaim glaubt
er habe registriert und muve hat immernoch kein passwort fuer den user
weswegen man genaugenommen nix tun kann...! sollten wir jabber clients
ueberhaupt zulassen ohne passwort!?
in jabber sind gaeste doch unsinn
die gaeste kann man mit SASL anonymous handhaben.
siehe xmppimpl.html, die Gäste sind dabei aber nicht in der Lage,
einen nickname zu spezifizieren
lynX muss sich das SASL anonymous zeug mal angucken,
ich kenne mich nämlich in der Benutzung der guest-flags im muve
nicht aus
- post-0.99 TODO: jabber clients are not interactives, there may be more than
one linked client per account.
im prinzip werden sie dann ähnlich wie psyc-clients behandelt werden und
damit haetten wir eine umfangreiche spielwiese fuer das zeug
- user.c should have a lot of common things with gateway.c and active.c
and component.c, so... inherit/include!
- vCard ist nur für sich selbst implementiert!?
* ja, schreib halt den nötigen code um von anderen zu requesten :-)
kann doch nicht sein, dass jeder jabber firlefanz zweimal gecoded werden
muss. können wir nicht eine gemeinsame API in user und gateway schaffen,
weswegen derselbe code im jeweiligen objekt das richtige tut???
: ich API'e schon soviel geht. aber gateway und user haben vollkommen
unterschiedliche anforderungen und so einfach, wie ich es mir in
disco.c gemacht hatte geht es nunmal nicht.
+ xbuddylist müsste auch den alias name speichern, den user ihren buddies
im client zuweisen können
das sollte in den alias'es sein. man kann afaik nicht einen user
mit zwei verschiedenen aliases in zwei gruppen haben
ja richtig - wir sollten psyc aliases und jabber aliases
zusammenschalten, dass der roster die aliases aus psyc erhält und man
beim bearbeiten der buddies einen alias auch für psyc setzen kann.
eventuelle leerspaces im namen müssen wir dann wohl durch _ ersetzen -
scheint kein problem darzustellen.
- wenn man im client einen alias ("name" feld im xml code) setzt beim
buddymachen, dann geht der im laufe der transaktion verloren und man
muss ihn später nochmal setzen!
- "00:05 ... Ich bin gerade nicht hier."
net/jabber/user maps away messages to mottoaction instead of presencetext
________________________________________________________________________
== JABBER FILE TRANSFERS ===============================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- beim versuch einen filetransfer zu initiieren zwischen zwei usern die ich
auf meinem localhost-psyced eingerichtet habe geht disco in eine endlos-
schleife, immer die folgenden zeilen ausgebend:
xmlns "http://jabber.org/protocol/disco#info"
<"iq"> <"/iq"> xmlns "http://jabber.org/protocol/disco#info"
<"iq"> <"/iq"> vars now ([ /* #1 */
"_jabber_XML": ""
])
kann es sein, disco.c antwortet auf jede disco#info mit ner eigenen?
müsste man da request und reply unterscheiden gehen? wie?
* disco hab ich großzügig neu geschrieben, sollte jetzt besser gehen
- nächste stufe der file transfers: bytestreams verwendet leider wieder
weswegen es nicht vom bisherigen innerxml-code erfasst wird. here goes:
» S:xmpp:217.10.9.40:-50348
» S:xmpp:217.10.9.40:-50348
» S:xmpp:217.10.9.40:-50348
» S:xmpp:217.10.9.40:-50348
» S:xmpp:217.10.9.40:-50348
« C:xmpp:jabber.ccc.de <
/iq>
(a) man sollte genereller aus allen seltsamen switch-lagen herausbreaken können
und zum defaultfall innerxml kommen. wenn das falsch ist kann man ja
stattdessen returnen..
(b) oder wir behandeln alle nachrichten die an eine resource gerichtet sind
mit dem innerxml code - können bei der gelegenheit auch das problem mit der
resource fixen. so sollte jabber routing ja eh funktioniert. gibt es einen
haken? muss muve an irgendeiner stelle für den client sprechen?
fippo: nein, nicht wenn die nachricht an eine resource gerichtet ist.
lynX: doch, es gibt exotische sonderfälle weswegen die stelle im gateway.c
die ich mit JTRANZ markiert habe *doch* falsch ist, um die entscheidung
zu treffen. schalte den debug an und schau lang genug zu. irgendwann kommen
dinge die der muve leider doch parsen muss um sie für psyc/irc/etc
aufzubereiten. ein gateway muss nunmal mehr tun als ein einfacher jabberd.
daher ist option (b) falsch und wir müssen (a) ins auge fassen.
fippo: nein. psyc/irc/etc wird nie mit resource senden. daher sind antworten
an solche auch nicht legitim
fippo: nach einiger ueberlegung muessen wir eine hybride strategie fahren
im gateway.c muessen wir wie dort beschrieben (b) machen
im user.c ist eher (a) angebracht
fippo: fuer message und presence ist das jetzt im user (a) implementiert,
im gateway (b). Fehlt zum einen noch der ganze -kram, zum anderen
schlaegt die haesslichkeit von raum%chathost@xmpp voll zu.
das muessen wir zum einen loesen, wahrscheinlich indem wir psyc://
codieren.
bei der presence ist noch ein markiertes todo, wem wir presence out
sandten und es beim logout als unavailable schicken müssen.
ich weiss dass das unintegriert ist in unsere places-geschichte, aber
so ist das nunmal
________________________________________________________________________
== RELEASE INSTALLER ===================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- _charset_console can still lead to unexpected convert_charset errors when
outputting random data. convert_charset must be non-fatal here!
? psyclpc should be in psyced snapshot pkg.. that means changing a lot
about the install.sh and the ebuilds.. oooph
- otherwise: teach install.sh or psyconf to copy sys-includes at
installation time to ensure we always have the ones matching the driver?
+ elmex says: ./install.sh -d(efault)/-l(astrun) to skip all the questions?
just ask? "Would you like to skip the questions and use last run's inputs?"
+ rpms! debs! ebuilds fertig machen und submitten!
- psyced.ebuild: saga meint wir sollten conf.d verwenden statt
/etc/init.d/psyced aus psyconf zu erzeugen. formell gentooiger quasi.
? psyced.ebuild: manpages für psyced und psyconf
? ldmud.ebuild: manpages für ldmud und erq
BuGless meint, um von den Distributionen wahrgenommen zu werden steht
folgendes an:
+ psyced muss posix-konformes kill und restart(exec)-verhalten haben
und empfiehlt 'cucipop' anzuschauen wo er strikt das von posix
verlangte mindestding implementiert hat.
+ das wrappende shellscript sollte weg.
+ das erste package für jede distri sollte man selbst machen, einfach
weil man selber am besten weiß was die software braucht. danach kann
sich immernoch jemand finden, der die maintance übernimmt, wenn man
das selbst nicht machen will.
... wenn diese punkte gut gemacht sind, sprechen die features von psyced
für sich. direkt zuständige leute ansprechen.
? in utility/Installer.pl liegt ein angebrochener ersatz für die fragestunde.
könnte nachladbarer teil von psyconf werden (-i flag), wenn es ein psyced.ini
erzeugt. das hinkopieren aller sachen und compilieren von ldmud müsste auch
noch in den Installer.pl. egal. im moment ist die arbeitsteilung zwischen
psyconf und install.sh ganz okay.
? sollten die sub.pm's von psyconf nicht eher in einer eigenen lib dir liegen
als verwirrt in utility? einfach lib/psyconf/ oder lib/perl/ anlegen?
+ fippo meint man kann jetzt drivers/ldmud/sys vom driver erzeugen lassen
lars meint:
'make install-headers' zusammen mit dem --includedir Option von configure.
? warn about running psyced/psyclpc as root?
- ensure /bin/sh is in /etc/shells. some braindead linuxes don't have it.
+ install.sh: runtime output should offer (console|buffered|flushed)
as alternatives. buffered := files, but "flushed" would be the use
of the new DEBUG_LOG feature for those who need unbuffered access
to debug output (tail-f-able).
- macosx entpackt tars!
noonee duftet: COMPILING LDMUD /ls: ldmud*tar.gz: No such file or directory / ATTENTION: More than one LDMud-dir found. Skipping.
bartman fragt: heißts vllt .tgz hinten? ;)
noonee duftet: nein, nur noch tar
noonee duftet: macos entpackt's halt schon
dann muss install.xx wohl lernen auch ein .tar zu akzeptieren
-> andere lösung, psyclpc ist im psyced tar mit drin..
- noonee duftet: configure: error: expected an absolute directory name for --bindir:
- ./install.sh: line 249: nslookup: command not found
several systems have no nslookup these days
- "LDMUD COMPILATION DONE" should check if erq and ldmud have been
compiled correctly
- on debian erq only compiles if '-lresolv' is appended. we need to
patch the ldmud Makefile for that!
? psyced.ini is missing a multiline syntax. and how do you specify
custom #define's for your local.h? we don't. we provide a local.h.
? should we fix WEB_CONFIGURE to act upon webgenerated.h only,
and not try to do things that psyced.ini does?
________________________________________________________________________
== MINOR TODOS =========================================================
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- maybe we should rethink our MOTD/BANNER logic.. and create one real MOTD
file being shown to all users (at least on request) and some special for
every access. ...... or just use the textdb for MOTD. maybe we can
provide edit tools for the textdb or at least the motd.
.... then again, ircd probably needs its own motd anyway .. just leave it
as it is, but move it into local/
- /version psyc://psyced.org and /version psyc://psyced.org/
doesn't work on psyced.org - localhost recognition goes ooga dooga
- on irc:
«psyc://beta.ve.symlynx.com/psyc:psyced.org» _error_illegal_uniform to 0 from 0: psyc://psyced.org is not a legal address here.
- textc T(mc, xx) API is insufficient to properly handle psyc inheritance
and at the same time handle formats provided by external apps. fippo's
fix in net/irc/common circumvents that, other psyctext apps skip inheritance
and use psyctext("", vars, data) with data now being used as template.
? allow admins even if LIMIT_USERS is reached?
- the DEALIAS() macro is incorrect. can we fix it and truly make use
of it everywhere?
- use shared_memory() for mmp_vars and maybe other static mappings
could even textc.c be simplified by going thru shared_memory() ?
+ /nickserv drop = /unregister - stop using a nickname. but why?
if you really want someone else to use your nick, give him the password.
+ /chanserv in net/place/standard - allow for known standard functions
in non-programmed places dynamically.
check /chanserv help on various ircnets.
- 20after4 says: I have noticed something strange related to disconnecting - if I connect to the same uni from another client, the first connection drops with the "fasten meat belts" message
? wir fangen subscribe requests an räume ab. was wäre wenn wir die
durchlassen? könnte man damit pubsub zeugs in räumen implementieren?
* pubsub hat nichts mit subscriptions zu tun. lies mal jep-0060
doch, lediglich dass es so viele optionen beherrscht, dass man in
psyc dazu ne hundertschaft an channels braucht.
nur was wollte ich eigentlich sagen.. dass /sub selbst ein /enrol
sein könnte? hmmm
? marenz suggests /sub could first ensure the target actually likes to be
subbed, that requires a tag-triggered action on reception of successful
entry.. and by consequence, should we also support current behaviour in
the form of /sub -f (aka force) ?
flags in chat commands? yeah why not.. it's a nerd thing anyway these days.
that means we need a getopt efun/implementation for LPC.. lol
? hmm.. htuniform() in http/library isnt being used by anything
why did i code it then? there must be a reason
? /x currently tells anyone about crypto level quality of a person
should this be more private?
+ METHOD FILTERING -> CHANNELS
fippo hotzenplotzt: hrmpf hrmpf. ich will webexamine setbar aushaben bitte!
lynx: programmier den ultimativen filter befehl
lynx: .. /filter