OK.. Thanks!! ________________________________ De: Gerald Young Para: User questions and discussions about OTRS. Enviado: Viernes 8 de febrero de 2013 15:20 Asunto: Re: [otrs] Need to set customers/agents's auth witn LDAP. "My Company Tickets"  -- everyone who needs them should have the same CustomerId.  http://forums.otterhub.org/viewtopic.php?f=60&t=7531 For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done. With regard to the conflicting notification systems, you did that to yourself. Or, more accurately, your corporate policy did that to you. "We need the following behaviour: when one agent replies something to customer in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text" Really? That's not OTRS fault. Who does that? You might as well yell at Microsoft because distribution group members don't receive emails sent by one of the distribution group member to someone who's not a distribution group member. Speaking of -- that is the solution to your problem. Create an email distribution group for each of the queues and cc or bcc that queue's distribution group when sending the Answer. It won't stop doubling, though. Turn off notifications in agent preferences. On Fri, Feb 8, 2013 at 9:03 AM, Vadim S. Goncharov wrote: On 08.02.2013 17:21, Steven Carr wrote:

On 8 February 2013 13:05, Israel Garcia  wrote:

...

OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my LDAP settings,

...

restart OTRS and volia!? Also, I have seen in Admin/SysConfig/Frontend::Customer::Auth the same parameters I have added to /opt/otrs/Kernel/Config.pm, should I edit them using this web page or editing directly the /opt/otrs/Kernel/Config.pm file?

Don't quite know about the "voila", more like cross your fingers and hope it doesn't collapse in a heap.

One of my big issues with OTRS is the configuration is utter crap. Too

There are many places in OTRS which are crappy. E.g. different conflicting notification systems (see e.g. bug #8953), and, on-topic, customer groups. We have group attibute in LDAP for customers, and simple intuitive and SCALABLE solution would be just use that word of customer to regulate access. But "My Company tickets" in OTRS requires comma-delimited list of "user1,user2,...user100500" for EVERY user. Brain-damaged.

many places to configure things, everything should really be just

...

configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need.

I'm not sure the order in which the settings are applied but I would guess that anything you put in Kernel/Config.pm will override anything you configure in SysConfig (someone can correct me if I'm wrong).

Yes. Actually, Config.pm is applied TWO times: before SysConfig, and once again after.

So just make your changes in one place and one place only and they

...

will be added to the overall config.

That's not always possible :)

-- Vadim Goncharov               RU-Center NET Department                            http://www.nic.ru NET-SYS Group             phone:+7(495)737-7646  (ext.4019)

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

On Tue, Feb 26, 2013 at 2:37 PM, Vadim S. Goncharov wrote:

On 08.02.2013 18:20, Gerald Young wrote:

...

"My Company Tickets" -- everyone who needs them should have the same CustomerId. http://forums.otterhub.org/**viewtopic.php?f=60&t=7531http://forums.otterhub.org/viewtopic.php?f=60&t=7531 <http://forums.otterhub.org/**viewtopic.php?f=60&t=7531http://forums.otterhub.org/viewtopic.php?f=60&t=7531

...

For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done.

From where have you obtained this information you've posted on forum? Docs, e.g. http://doc.otrs.org/3.2/en/**html/external-backends.html#** multi-customer-ids-ldaphttp://doc.otrs.org/3.2/en/html/external-backends.html#multi-customer-ids-ld...- don't say anything about CustomerID is really CompanyID and that way will work. Only comma-delimited field is described. OTRS docs had always been bad, though...

From where? The code. The code says that customer_id is the value that is checked for the tickets that can be seen by a customer in "Company Tickets". There is no such thing as "Company ID" but unofficially, I and others call customer_id "CompanyID" as it is essentially what customer_id represents. It is an attribute in free text attached to the ticket in the ticket table.

Can you guarantee that changing `customer_id` on all tickets (or what I supposed to do to enable this feature?) will break nothing, and that developers won't change this mechanism in future versions? I've digged a lot of OTRS code, but not all, I'm not sure even about current state, not even future.

No guarantees. If it breaks, you get to keep both pieces. But seriously, you CAN break it by overloading fields or something. I'm not going to tell you what it will or will not break for you, but I will tell you that customer_id is primarily used for two purposes: 1) linking a company (when company support is enabled) to a customer and 2) to determine the tickets visible in Company Tickets.

With regard to the conflicting notification systems, you did that to

...

yourself. Or, more accurately, your corporate policy did that to you.

That's not a good approach to describe why things are so broken and then do nothing instead of thinking how to reach the goals - to fix them. There is nothing very special in this corporate policy, and it could easily be implemented, if some more options in OTRS had existed.

This is a special policy. You are the first and only person who has presented in public forum in the past 3 years I've watched this that you are corporately required to send all outbound-to-customer responses to all agents in a queue. This is unique to you. It may not be special, but it's definitely not something that *generally* makes any sense to implement for the rest/majority of us.

Here's another bad thing about OTRS - I've proposed "Guys, I could do this work for you and contribute, just say what are your plans in this area to have no conflicts" there in bug report. But the bug remains in NEW state for already THREE months!

"We need the following behaviour: when one agent replies something to

...

customer

in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text"

Really? That's not OTRS fault.

It is. OTRS not send a notification about notification it has already automatically generated itself. Or have I say "thanks" to this being only just one garbage message instead of infinite loop of them? :)

Who does that? You might as well yell at

...

Microsoft because distribution group members don't receive emails sent by one of the distribution group member to someone who's not a distribution group member. Speaking of -- that is the solution to your problem. Create an email distribution group for each of the queues and cc or bcc that queue's distribution group when sending the Answer.

And then every agent on every answer must fill Cc:/Bcc: by hand? Why ever men should bother about things machine could easily do? Why should I put more work on people because of bug?

Yes, this is your policy. It's not normal. Read my paragraph above. You are asking for exactly the same thing as what I posted. How would you make Outlook behave according to this? This is not a bug. This is a feature request.

It won't stop doubling, though. Turn off notifications in agent

...

preferences.

You didn't read carefully, doubling was fixed in bug#7407, now it just one garbage message (body solely of '-' char) to agents on autoreply to client. Actually, for our agents not even so, because I fixed this with a dirty one-line patch to appropriate .pm. I don't submit it, though, because it is not a solution to a broken system but the crutches to local situation (solutions were proposed in bug report).

So, you are part of the problem for not submitting it?

"it is quite logical here that people in each subdivision must know what their colleagues do on behalf of sibdivision's work." Yes, but they don't *have* to be told that it happens. Also, what's the point? Can they do anything about it? No, they just get told "hey, somebody replied to a ticket" ... The same information, if they cared, they could see from OTRS. But they don't, because it's not their ticket. "There are just not enough events" Do tell. What kind of event is missing? Or, how many events do you need before you consider "there are enough events"? "processing of existing event is somewhat broken" Ambiguous statement is ambiguous. "Do you really propose sending dirty hacks as bugfixes? Seriously? (btw, I've already had to fix another broken part, 'coz patch is, um, dirty). " The alternative being to complain that it's not fixed correctly? Even if the hack is "dirty", it's actually your responsibility to provide it to anyone who asks who uses your code. (GPL) Just because you hacked it doesn't mean that it has to be accepted and incorporated as core code verbatim. You're not QC. You're simply giving your version of, "I fixed it this way." Yes, provide the dirty hacks as bugfixes. If it works for you, it might work for someone else. Until something official/better comes along, your code *is* (likely) the best way to handle it. For Guarantees: Kernel/Modules/CustomerTicketOverview.pm CompanyTickets searches CustomerID. If the current user has a CustomerID or one of CustomerIDs, that matches that stored with the ticket $Self->{UserObject}->CustomerIDs( User => $Self->{UserLogin} ), it will be shown in Company Tickets. CustomerIDs is in Kernel/System/CustomerUser.pm and referenced in CustomerUser/DB.pm and CustomerUserLDAP.pm Whether delimited with semicolons, commas, or pipes: # used separators for my $Split ( ';', ',', '|' ) the values of customer_ids are obtained and then on that array, pushed the CustomerID.of the current customer. # use also the primary customer id if ( $Data{UserCustomerID} && !$Self->{ExcludePrimaryCustomerID} ) { push @CustomerIDs, $Data{UserCustomerID}; } This array/list is then sent to the CustomerTicketOverview module, which searches against that list. "What happens if you change the customer_id in a historical ticket?" Not much, ticket-wise. (This based also on personal experience). It won't prevent a user from accessing her own ticket, but may change her permissions regarding visibility in "Company Tickets" "Do you think they'll change this paradigm?" No. Not that I'm 100% sure on this, but considering how integral it is to accomplishing this goal, I can't imagine that they'll change it any time soon. Look at what the CustomerID *does*, especially with what happens when CustomerCompanySupport is enabled. This is a critical function to just arbitrarily change for the sake of "New version, let's just throw this out." "But no documentation" ok. read thishttp://doc.otrs.org/3.0/en/html/x2282.html#multi-customer-ids-dband then understand that the default mechanism of OTRS is that everyone has a different customer_id. There are essentially three ways to make "Company Tickets" work in practice. 1) A real pain in the butt, but a Supervisor has a customer_ids field of all the individual customer_id whom he watches. 2) Everyone in a company or department has the same customer_id (and sees all everyone's-with-the-same-customer_id tickets in Company Tickets) 3) Everyone in a company or department has the same customer_id, but only the Supervisor or Department Manager sees "Company Tickets" (CustomerGroupMembership for access privileges) and multi-department supervisors have customer_ids of departmentA,departmentB Look at the code. If the result of "CustomerIDs" includes all of the current customers' customer_ids (if exist) AND the customer_id, and this is what's being used for TicketSearch for Company tickets. OK, so the ability to reuse customer_id is undocumented. I figured it out, so I'm sharing the knowledge. Until something official/better comes along, my post is (likely) the best way to handle it.

"that's a story about another flaw" No, it's just not what you would do, but it's the way the system works. It's not your ticket to fix. It's the locked owner's ticket to fix. It's specifically so you don't barge in there confusing both the agent and the customer on who, exactly, is handling the ticket. The proper way to do what you want is to create a Ticket Event. It's not a bug. Nobody but you needs it, and it's not necessary in core code, and will likely keep across upgrades. "how?" http://forums.otterhub.org/viewtopic.php?f=60&t=10090 Psuedo code: Check for ArticleSend Get the queue for the ticket. Get the queuegroup Get the members of the group Get the message that's being sent Send to the members of the group It's all nice, neat, tidy, and yours. On Fri, Mar 1, 2013 at 1:34 PM, Vadim S. Goncharov wrote:

On 01.03.2013 21:47, Gerald Young wrote:

...

"it is quite logical here that people in each subdivision must know what their colleagues do on behalf of sibdivision's work." Yes, but they don't *have* to be told that it happens. Also, what's the point? Can they do anything about it? No, they just get told "hey, somebody replied to a ticket" ... The same information, if they cared, they could see from OTRS. But they don't, because it's not their ticket.

That's simply not true, because it depends on workflow. Our agents receive full text copy, not just "somebody replied". As an example, just today I saw messages of the ticket locked by another agent in one of my queues, and decided to care, and helped that agent and originator. I was forced to leave note-external, though, because ticket was locked and I couldn't answer, but that's another story about another flaw.

"There are just not enough events"

...

Do tell. What kind of event is missing? Or, how many events do you need before you consider "there are enough events"?

Are you trolling? I told this several times already, referring to text of bug#8953, in which I described possible solution.

"processing of existing event is somewhat broken"

...

Ambiguous statement is ambiguous.

"Do you really propose sending dirty hacks as bugfixes? Seriously? (btw, I've already had to fix another broken part, 'coz patch is, um, dirty)." The alternative being to complain that it's not fixed correctly? Even if the hack is "dirty", it's actually your responsibility to provide it to anyone who asks who uses your code. (GPL)

Of course my patch is available to everyone in my company. You missing the point that complain is not about "not fixed", but rather "they don't give me information about preferred way to change that subsystem". That's a difference between "I want them to do the work" and "I want to hear there are no barriers for me to this work for them".

Just because you hacked it doesn't mean that it has to be accepted and

...

incorporated as core code verbatim. You're not QC. You're simply giving your version of, "I fixed it this way." Yes, provide the dirty hacks as bugfixes. If it works for you, it might work for someone else. Until something official/better comes along, your code *is* (likely) the best way to handle it.

Once again, there are not just 2 alternatives "they fix" vs "my dirty hack", but I prefer 3rd "I could do better, if given some info". It is really much simpler to write several paragraphs of me, and I will code, rather than do the work themselves, right?

For Guarantees:

...

Kernel/Modules/**CustomerTicketOverview.pm CompanyTickets searches CustomerID. If the current user has a CustomerID or one of CustomerIDs, that matches that stored with the ticket $Self->{UserObject}->**CustomerIDs( User => $Self->{UserLogin} ), it will be shown in Company Tickets.

CustomerIDs is in Kernel/System/CustomerUser.pm and referenced in CustomerUser/DB.pm and CustomerUserLDAP.pm Whether delimited with semicolons, commas, or pipes: # used separators for my $Split ( ';', ',', '|' ) the values of customer_ids are obtained and then on that array, pushed the CustomerID.of the current customer. # use also the primary customer id if ( $Data{UserCustomerID} && !$Self->{**ExcludePrimaryCustomerID} ) { push @CustomerIDs, $Data{UserCustomerID}; }

This array/list is then sent to the CustomerTicketOverview module, which searches against that list.

"What happens if you change the customer_id in a historical ticket?" Not much, ticket-wise. (This based also on personal experience). It won't prevent a user from accessing her own ticket, but may change her permissions regarding visibility in "Company Tickets" "Do you think they'll change this paradigm?" No. Not that I'm 100% sure on this, but considering how integral it is to accomplishing this goal, I can't imagine that they'll change it any time soon. Look at what the CustomerID *does*, especially with what happens when CustomerCompanySupport is enabled. This is a critical function to just arbitrarily change for the sake of "New version, let's just throw this out." "But no documentation" ok. read this <http://doc.otrs.org/3.0/en/**html/x2282.html#multi-**customer-ids-dbhttp://doc.otrs.org/3.0/en/html/x2282.html#multi-customer-ids-db> and then

understand that the default mechanism of OTRS is that everyone has a different customer_id. There are essentially three ways to make "Company Tickets" work in practice.

Surely I read this doc. And I referred to it several times already in this flame (though you skip the quoting). The problem is that this doc does not _imply_ that CustomerID is non-unique, and it is actually a CompanyID. Instead, it forces the impression that your way #1:

1) A real pain in the butt, but a Supervisor has a customer_ids field of

...

all the individual customer_id whom he watches.

...is the only possible way to solve the problem. This is not even something obvious if you even read some code, because OTRS is big, and nobody reads all relevant code at once. E.g. I didn't ever dig to CustomerCompanySupport, which is key to understand the actual meaning - because we don't use it, and answer for the question in doc don't give a clue to look there.

2) Everyone in a company or department has the same customer_id (and sees

...

all everyone's-with-the-same-**customer_id tickets in Company Tickets) 3) Everyone in a company or department has the same customer_id, but only the Supervisor or Department Manager sees "Company Tickets" (CustomerGroupMembership for access privileges) and multi-department supervisors have customer_ids of departmentA,departmentB

Look at the code. If the result of "CustomerIDs" includes all of the current customers' customer_ids (if exist) AND the customer_id, and this is what's being used for TicketSearch for Company tickets.

OK, so the ability to reuse customer_id is undocumented. I figured it out, so I'm sharing the knowledge. Until something official/better comes along, my post is (likely) the best way to handle it.

Yep, and I will use it, of course, thanks. Just need to clarify the point that this fact, and your effort, doesn't cancel another fact "doc is poor".

-- Vadim Goncharov RU-Center NET Department http://www.nic.ru NET-SYS Group phone:+7(495)737-7646 (ext.4019) ------------------------------**------------------------------**--------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/**pipermail/otrshttp://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/**listinfo/otrshttp://lists.otrs.org/cgi-bin/listinfo/otrs

The database is the only logical place for that information to live Static connection information? Maybe not. Configuration? ... I'd be inclined to concur. The problem with the database method with a table based data source is the freeform data. Move it to something non-sql, like perhaps ldap or other NoSQL, and this should be much better handled as desired.

On Fri, Feb 8, 2013 at 10:29 AM, David Boyes wrote:

...

One of my big issues with OTRS is the configuration is utter crap. Too many places to configure things, everything should really be just configured through Sysconfig instead of having to mess about with text files (and perl based text files at that), and ideally stored in the database to make upgrades a lot easier than worrying about which config files you need and don't need.

Amen, brother.

Software this complex needs to have settings in one, migrateable place with clear exit points for customized processing of those settings. The database is the only logical place for that information to live.

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

otrs crontab comes from running bin/Cron.sh start otrs it concatenates all files in var/cron/* that do not have .dist appended. On Fri, Feb 8, 2013 at 11:01 AM, Israel Garcia wrote:

Hi again,

Sorry if I'm writing continue to the list, but I have realiza that for an unknow reason user otrs have not crontab. How can I recover this file? I have not yet a backup installed.Can any send me the /var/spool/cron/otrs file?

Thanks much!!! Apreciate your help..

Regards, Israel.

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

nice!! Thanks tons ________________________________ De: Carlos Andrés Gallego Arboleda Para: Israel Garcia ; User questions and discussions about OTRS. Enviado: Viernes 8 de febrero de 2013 17:11 Asunto: Re: [otrs] I have lost otrs crontab..pls help! Hi You can use this. cd /opt/otrs/var/cron for foo in *.dist; do cp $foo `basename $foo .dist`; done cd /opt/otrs bin/Cron.sh start otrs From OTRS WIKI http://wiki.otterhub.org/index.php?title=Installation_on_Ubuntu_Lucid_Lynx_(...) 2013/2/8 Israel Garcia Hi again,

Sorry if I'm writing continue to the list, but I have realiza that for an unknow reason user otrs have not crontab. How can I recover this file? I have not yet a backup installed.Can any send me the /var/spool/cron/otrs file?

Thanks much!!! Apreciate your help..

Regards, Israel. --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

On 02/08/2013 11:22 AM, Steven Carr wrote:

On 8 February 2013 15:55, Gerald Young wrote:

...

...

The database is the only logical place for that information to live Static connection information? Maybe not. Configuration? ... I'd be inclined to concur. The problem with the database method with a table based data source is the freeform data. Move it to something non-sql, like perhaps ldap or other NoSQL, and this should be much better handled as desired. Yes I agree that there does need to be a level of configuration that needs to be maintained like database for the initial connection, but other than that I don't really care what is used as the backend storage for the config. They can continue to use flat files, but it must be a single location: db, single file or folder (containing live config and live config only, no other random backup or crap files) that can be picked up and dropped into another system to make upgrades "easier".

I've fallen into the pit of despair in v2.x by customising OTRS heavily then spend 3 months trying to upgrade it and fix the previous customisation, so now with v3 I tend to stick with "stock" OTRS, but even then it's still a right PITA to upgrade as it's so intertwined with the data and config that it consumed, no clear boundary.

Steve

It is a real problem that some config data is in both places. States for instance are defined in the database but are also in Sysconfig based on the "text" of the state. So you can change the state "new" to "New" and now suddenly when you go to create a ticket since the default state in Sysconfig is "new" things break. -- Stephen Clark

On 8 February 2013 16:37, David Boyes wrote:

Actually, it’s not that bad.

At the most basic level, you can treat the static info as an array of text lines and read/interpret them sequentially. That at least doesn’t bind the information to a file on a specific server and gives you much more granular control of configuration management on operating systems that have essentially only two privilege levels (root/non-root).

As an interim step on that clustered OTRS system I mentioned in another thread, we’ve stored the config files in git and modified the OTRS startup script to check out the configuration files from the git server based on the node id at startup and a “current configuration” tag. The basic principle is sound (and you get very detailed configuration control) – it wouldn’t be too hard to migrate to storing the static info in a table.

Where do you see the big problems?

With all due respect David your system is highly customised and you must have the people power (or skills) to maintain your custom setup. I don't want to have to do any of that custom piece, and more to the point I shouldn't have to do that. I want OTRS to focus on putting an enterprise/more manageable/maintainable slant on things, rather than it still feeling very much like a pet project that needs constant nurturing. And yes there is the argument that it is "free"/open source so take it or leave it, but even the paid version doesn't really offer any advantages other than 101 unnecessary add-ons and someone on the end of a phone to answer questions, and I'm technically competent enough not to need to pay someone for that. Since the change of hands it's beginning to feel very much like a closed application they just happen to release the code to, the community development side of the project has gone leaving very little ability to request/influence development. Steve

On 8 February 2013 16:37, David Boyes wrote:

...

Actually, it’s not that bad. With all due respect David your system is highly customised and you must have the people power (or skills) to maintain your custom setup. I don't want to have to do any of that custom piece, and more to the point I shouldn't have to do that.

I think you misinterpreted my reply. I was replying to Gerard's note on the difficulty level of storing connection info with the "not that bad" comment to illustrate that a solution like we're discussing wouldn't be that hard to implement. I'm totally with you on the "we shouldn't have to invent hacks like this" -- that idea with git is a workaround, and for enterprise-grade infrastructure such as OTRS purports to be, hacks like that shouldn't be necessary. We're not breaking new ground here; most of what we're discussing has long ago been done in other tools, and there's little excuse for not learning from the past. (I'm coming from a mainframe background, so the fact we have to do any of this HA stuff at the application level continues to amaze -- the mainframe world had this kind of basic system integrity stuff in 1982 for *everything*, not just single apps inventing it as they go along. ) I tossed out the git idea as one way we worked around the problem. It's fugly, but it does work as a stopgap solution. There is some unavoidable formalism that it assumes in terms of administrative practice, but nothing that you wouldn't expect from good practice where downtime has a substantial price attached to it. We built it on git precisely because we didn't have to invent the management of the configuration versioning, and we used it elsewhere, and it didn't require modifying OTRS beyond a simple init script change, which is easily managed (in fact, if I were doing it now, I'd pull that step out of the OTRS init script and put it into a new script with appropriate dependencies). It shouldn't be necessary, but it lets us cope with the problem without rewriting the universe. There are a lot of things I'd like to see added for HA and system resilience in OTRS. Matter of time and resources, I'd say. It probably would be a good idea to discuss it here, and help them define some requirements for what a really resilient enterprise OTRS system would look like. My "starter" list would be: 1) tolerate/exploit clustered database engines 2) explicit interaction with load balancing solutions (start with LVS, move on to the hardware solutions later) 3) rationalization of configuration data 4) management of configuration data 5) work on lock management in the database (there are a lot of places where a table-level lock is used by default that could be much more efficiently use row-level locks) 6) More work on index definition for high-use tables 7) Allow explicit use of different database extent storage pools in the database scripts to tune data placement (indexes on SSD, data on slower disk, for example). 8) More formal work on the SOAP interface. XML-RPC only goes so far. 9) a instrumentation interface to determine how well the application is performing (per-request timing, transaction overhead would be a good start)