![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: C API limitations Topic Summary: Created On: 24-Nov-2003 22:49 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Interesting thread and I have been thinking the same thing lately. The single thread limitation of the client drives obvious limitations in a web environment, which is typically not a "single" threaded environment. The API provided carries along the same limitations so I dont think that their is much that can be done at this time. Ive been lately thinking of building some "wrapper" applications for web purposes that would compensate for the existing limitations. Ive been working with doors for a couple years and the same questions and issues keep coming up so I figure now is as good as time as any to start exploring this. Im looking at building a set of tools in java that encompass some of the functionality that is not available in the existing Telelogic toolset - web/db access, upload/extract/xml, license management (not really telelogic, but since they use flexlm I consider it included), reporting. If anyone is interested in collaborating drop me an email Marc | |
![]() |
|
In the solution that I want to implement, it seems the clever scheme of scripted IPC that's been devised is adding quite a bit of complexity to the design. It would be wonderful if the API could be modified to overcome two limitations: only one IPC channel can be managed by the API library at a time, and there is no direct interface to the actual DOORS server that doesn't go through an intermediate DXL Server.
My company has a web-based application where users browse process management information. Certain data presented is related to information maintained by DOORS. Users would like to be able to easily click a link to see this related information. The concept is simple; but the devil is in the details. It seems that if I want to support concurrent requests from multiple users, I'm going to have to CreateProcess() two processes for each request handler. One process is the DXL server that actually connects to DOORS, and the other would be the process that provides a callback to receive the text data. The latter process can't maintain more than one IPC channel due to the API library's limitation on this, which is why I will have to start up two processes for each request handler. On top of that, I have to implement another multi-threaded process to kick off these processes and herd the reqests and responses among them. In my mind this is an incredibly circuitous way of doing things especially since I only want to deal with text data between the web service and DOORS. And a cleaner solution could be coded completely in C/C++ without the need to delve into a scripting language that isn't generally known among members of my development team. Am I missing something? Is there actually a direct method of interacting with the DOORS server that either isn't documented, or that I missed in existing documentation? Or do my observations seem accurate. What other alternatives to extracting data from DOORS and displaying on our webpages are there? Edited: 25-Nov-2003 at 02:03 by Todd Tapper |
|
![]() |
|
![]() |
|
Todd,
I'd have to say that you have stated the problem rather well. I know of no way to directly access the DOORS data other than their API. There are DXL routines that can generate HTML for the data that is in DOORs but I haven't had the pleasure of needing to perform this type of operation. I am very interested in knowing how you plan on moving forward (if at all) with your solution because we very well may have to travel down that path. Sorry I couldn't be of more assistance. Good luck. |
|
![]() |
|
![]() |
|
Your observations are acurate.
I am also lacking a proper API. I need to have some libraries that I can compile with my own code to access the DOORS db. I have written a two way web interface to the DB using the DXL API. Actually it works quite ok, but it is a bit slow. It stopped working when I migrated from 6.0SP1 to 7.0. But I still have the code |
|
![]() |
|
![]() |
|
Got to say we've generally gone with the option that Roger mentioned of doing batched readouts of data, the API appears to be rather poor and the API manuals are poor.
------------------------- Graham Stradling, Alcatel-Lucent. |
|
![]() |
|
![]() |
|
Can you post your code? With the very limited information on the DOORS API, it would be great help.
Thanks in advance! ------------------------- Bruce Tuskey Sr. Principle Engineer Tuskey@gmail.com "All that is gold does not glitter, not all those who wander are lost:..." - Gandalf the Grey (JRR Tolkien) |
|
![]() |
|
![]() |
|
Interesting thread and I have been thinking the same thing lately. The single thread limitation of the client drives obvious limitations in a web environment, which is typically not a "single" threaded environment. The API provided carries along the same limitations so I dont think that their is much that can be done at this time.
Ive been lately thinking of building some "wrapper" applications for web purposes that would compensate for the existing limitations. Ive been working with doors for a couple years and the same questions and issues keep coming up so I figure now is as good as time as any to start exploring this. Im looking at building a set of tools in java that encompass some of the functionality that is not available in the existing Telelogic toolset - web/db access, upload/extract/xml, license management (not really telelogic, but since they use flexlm I consider it included), reporting. If anyone is interested in collaborating drop me an email Marc Edited: 12-Feb-2005 at 06:19 by Marc Battistello |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
C API limitations
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.