[IRCServices Coding] Nickname linking/coding question

[Andrew Church]

     So it looks like the differences are (1) separate memos for separate
nicks and (2) keeping the same nick on the channel access list.  I think
(1) is a PITA; (2) is a good idea and something I've been thinking about
(e.g. store nickname in ChanAccess as well) but a low priority.

     You're of course welcome to fork Services and start your own project;
that's what open source is about, after all.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>It's a system that allows all linked nicknames to still have their own
>memobox. When you switch to a linked nickname, it'll say how many memos you
>have, and how many you have on your linked nicknames. It also allows you to
>add links to the currently used nickname, which is what I was inquiring
>about. Channel entries still display the nickname that was originally was
>added.
>
>Basically, all of the nicknames exist on their own; they aren't copies of
>each other. The system itself only does two basic things:
>    a. when you identify, it automatically identifies to all linked
>nicknames
>    b. if you join a channel and have a linked nickname in the database,
>it'll see that and auto-op you.
>
>It also allows cross-linking. However, I'm probably going to want a system
>that automatically crosslinks them (which ircservices already does
>indirectly)..
>
>In my opinion, the new nickgroup code seems a bit of an overkill for what
>I'm trying to accomplish. The system I'm wanting to use could probably be
>built by using the original nickname structure (ni) and adding an array or
>something similiar to the new structure (ngi) that points to the linked
>nicknames and various pieces of information.
>
>I'm sure there's a better way that I haven't thought of. Suggestions are
>welcome. ^_^
>
>I think I'm definitely going to stick with my current base instead of
>converting to the style 5.0 uses though. It seems a bit tedious to work
>with.. Don't get me wrong - you've done well so far and the idea of a
>services package with module support is a great idea, but when you have to
>search through function after function (and usually in 3-5 files) in
>unfamiliar code to find something being called, it becomes too much work.
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding