[IRCServices] Services Protocol for InspIRCd 1.2

[Robin Burchell]

Therein lies the problem. Most protocols are (now) far too divisive
and seperate from the RFC, so a more generic approach is required
(feature based instead of syntax based). For example, UID support is
implemented in TS6 (ratbox, hybrid, charybdis), P10 (undernet,
beware), and us (almost TS6, but not quite). From that, you'd get a
function pointer to a function generating UIDs, and let the protocol
module override that as necessary.

I realise that a feature-centric redesign of the protocol support is
indeed outside the spec of what you're working in now, but perhaps it
may be an idea to note such an idea in the technical manual.

I have started some similar (rather horrific, preliminary) work in a
5.0 fork from a while back - though I doubt you'd find it necessary to
review, let me know offlist if you wish to do so.

Thanks,
Rob

On Nov 12, 2007 11:30 AM, Andrew Church <achurch at achurch.org> wrote:
> >The way we quick-converted our source base over was more or less:
> >  - Convert FindNick to find by UID if isdigit(*nick)
> >  - Store UID in the user structure (you'll need to generate/store for
> >pseudoclients too, though, I guess. Though that code isn't too
> >complicated.)
> >  - ???
> >  - Profit!
>
> This works fine as long as you've only got one protocol to worry about.
> Services has to think about others, so it's not quite as simple
> (particularly since I've taken the approach of centralizing as much code
> as possible, which includes message handling to an extent--if you assume
> a certain level of RFC compliance, it's just a waste of effort to write
> a whole bunch of functions in the protocol modules that all do the same
> thing.  In the end, it's really a question of how invasive the changes
> required are... if I can solve it with something like an id_to_nick()
> routine in each protocol module, that's probably manageable, but if it
> means rearchitecting Services itself to handle non-nick client IDs,
> that'd be beyond the level of maintenance support I'm contemplating.
>
>
>   --Andrew Church
>     achurch at achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>