Carey, your post didn't sound negative towards ARSperl. Even if it did, your feedback would still be welcome.
Maybe I'm able to shed some light on the issues that you have addressed. ARSperl does indeed not implement any of the ARGetMultiple* calls, with the notable exception of ARGetMultipleEntries. Nor is it possible to limit the ars_Get* functions to specific attributes (again with the exception of ars_GetEntry). The reason for this is that the developent of ARSperl, like the ARS API itself, is somehow quite "vendor centric", the "vendor" in this case being a group of volunteers, especially myself. To state it more directly: if I need something, then I'll implement it. The ARGetMultiple* functions don't have very high priority from my point of view, since their functionality is already provided by the ars_GetList*, ars_Get* functions, so it's only a matter of performance. Of course perforance is important, but the sort of programs for which I would use the ARGetMultiple* functions (e.g. creating a report of all fields in an application) usually don't require that much performance. If it runs maybe only once a week, then it's okay if it takes a few minutes. Please note also, that for entries, where permormace is probably the most important, there are ars_GetMultipleEntries, ars_GetListEntryWithFields as well as ars_BeginBulkEntryTransaction and ars_EndBulkEntryTransaction. Another reason is that we rather seldom hear from users about shortcomings or desired features, so again every feedback will be welcome. I'd be quite interested what the "complex tasks" where for which ARSperl eventually turned out to be too limited. The ability to limit ars_GetWhatever() attributes is something which I've wanted myself sometimes, so this has a relatively high priority for me, at least concerning fields. The performance of ars_GetFieldTable, which is also used to populate the internal field cache (necessary to build the ARS API data structures for ars_CreateEntry/ars_SetEntry calls) would probably be much better if it used ARGetMultipleEntries. I'm currently working on this, so it will be definitely implemented in the next release. Thilo Stapff Carey Matthew Black wrote: > Franklin Lee, > > Note: This post may sound "negative" towards ARSPerl. It is not > intended to be. My understanding of ARSPerl's reach and range may be > limited as I have not seriously used it for some time now. ( FWIW: I > have moved on to the Java API. ) I do still use it some, for the tasks > that it is "best suited" for, but I have often found limits in my > abilities to use the wrapper to do "complex tasks" with ARSystem. > > > In general, I have often found that people that I will call "true > programmers" look at the ARS api and are left scratching their heads > over the choices that were made when the api was being laid out. > > To be clear, what you think of as "inefficient" may not be as bad as > you think. (And there maybe options that ARSPerl simply does not yet > implemented, or exposed to it's users too.) > > FWIW: The C and Java api's support a great deal of granularity as to > the level of details that you can get about the objects in the get* > api calls. So you do not have to get all of the field details when all > you want is the "fOption" settings for all of the fields. Yes you do > have to make a trip to the server for every field. However that is > simply because there are no advantages for the vendor (Remedy, and now > BMC Remedy) to have a single API call that returns that specific range > of details for all fields on a single Form or even "All Forms on a > server" for that matter. > > I am however, unclear if the ARSPerl wrapper around the C API offers > the ability to limit the details that will be fetched for the > ars_GetField call. (It looks like there are no inputs to achieve that > goal.) For that matter I can not tell if ARSPerl has implemented the > ARGetMultipleFields API call either. The published HTML docs do not > appear to reference theARGetMultipleFields function specifically. In > fact the HTML docs give the impression that ars_GetFieldTable > specifically uses "ars_GetListField and ars_GetField". But I must add > that it is possible that the ARSPerl wrapper does include a way to > call the underpinning C ARGetMultipleFields API and it may not be > documented yet too. > > You may also find that getting all details about a form will produce > the data set you need. However, you may need to walk the data returned > in ways that are not provided by the ARS API too. > > The AR System is a 3 tiered system. Client, Server, and RDBMS. The > vendor has made decisions about that tasks will be done by each of > those layers for their own reasons. (And there is no written > explanation that I have ever come across.) > > Often programmers expect the Server (ALA: ARS API ) to do things that > I believe were deemed to be the responsibility of the client layer. > (There are many examples, not the least common of which has to do with > desires to programmaticly dissect, construct, or manipulate ARS > objects in mass. Which are generally not implemented in the provided > clients. Even when they are simulated in the provided clients I > greatly suspect they are simply looping over the objects selected and > calling multiple single get/set/create API calls for each one.) > However, over they years as the AR System application reach and range > improved the ARGetMultiple* API calls were added to help with some > (not all) of these needs that the vendor started to face for their own > clients functionality. > > Please keep in mind that while the AR System API is expose to the > customer that I have long believed that its design and purpose is very > vendor centric. The gaps may be there simply because the vendor does > not have the same needs, or they might be there to intentionally leave > gaps that make it harder for customers to totally replace the vendors > clients. ( You can reach either conclusion easily and likely can find > "evidence" to support both positions fairly easily.) > > But long story short... > > So as a wise teacher often says.... The rest is left to the student > (er.. Client in this case) to implement. > > If you speak Java, you should will find the Java API to be more > complete. (and in theory, "supported" directly by the vendor.) > > I hope some of that helps. > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- Arsperl-users mailing list Arsperl-users@arsperl.org https://lists.sourceforge.net/lists/listinfo/arsperl-users
