Actually, there is a better alternative. Please excuse me for taking a braindump here...
It would really pay to have a single xs method that flushes the command queue. At present when commands like say or emote or whatever are called in perl, they are stored in a command queue. When the event sub is done, the commands are executed and dequeued. Writing a single xsub to trigger the process of flushing the queue would save you from having to write a new xs for each future value-returning function in the future. To call a c function, you'd make a perl wrapper function (like the ones at the end of embparser.c) that also calls the xsub to flush the queue and passes a return value back to the caller if necessary. The code for emptying the queue is already extant in the sendcommands function, it just needs to be hooked by a xsub. As long as appropriate care is taken in handling the return values, the c function to be exported can even still be parsed in the parse_commands function, allowing it to also be used by the native parser.
Then again, maybe it isn't worth the effort. The only place I see a possible need for further functionality ATM is in DB access (possibly using eqsharedmem as a conduit). Due to bandwidth constraints, I can't run a high load server. Therefore, I can't really evaluate the efficiency of directly querying the db via a globally cached dbi::mysql conn. It is certainly possible to query/modify the db that way, though. SQL statements can even be precompiled and cached. This is certainly a workable arrangement for simple queries on low load zone servers. I can't say how well it would scale, though.
Now... back to the $itemlink thingy... I don't see why anything special needs to be done to support that. Decide the format of your function and then parse it out in sendcommands... i.e.. if(find(args.begin(), args.end(), "itemlink(")) -> do some stuff instead of passing it on to excommands.
|
Threaded Mode
