New Poll: To API.... or Not to API?

[christopher.zoog51272]

With the recent heated "API" discussions here and on alt.cad.revit, i thought it was high time for another handy dandy poll! So the question this time: Should revit allow for an application programming interface to allow 3rd party development of tools or would you rather Autodesk supply all the necessary tools without resorting to third party support? The are pros and cons either way. Think about it.....then vote!

[Steve_Stafford]

Make mine a Naah...you know I realize it iritates the heck out of people who like to do that stuff, but I do NOT miss autolisp. Using Revit for quite awhile now, supporting AutoCAD/ADT is a drag now. Lisp this, Lisp that...menu this...variable that....

I do appreciate the "possibilities" that exist with an API...but I really do appreciate and prefer that the improvements that take place are thoroughly examined and implemented properly by the team that created the product.

I could be swayed if an API made the data for schedule creation and analysis more versatile. But I do not want to get into the level of management currently involved with the other product(s).

Take a look at the cottage industry for customizing them in the course list of AU...there are WAY more classes on programming than Revit!!

One personal parting shot...before Revit I imagined my career in terms of AutoCAD/ADT as a cadd admin overshadowing a career as an architect. Revit and it's "simplicity" has allowed me to re-imagine myself as an architect more than a "technocrat". Good for me, and possibly good for many folks more interested in being a great architect than a great cadd guy!!

[Scott Hopkins]

I am going to have to agree with Steve on this one. I think opening up the program for outside development is huge mistake. With and open API the Revit design team will undoubtedly begin to slack-off while outside programmers develop new feature sets for Revit. Once a new tool is created outside of the program, it is rarely incorporated into the base program. I think program designers are worried about alienating API developers. Users of the program end up needing to purchase half a dozen separate add-on programs at $100-$300 a piece to use the base program effectively. Aside from the added expense, managing all of these extra programs and licenses becomes a huge time sink.

The reviews of Revit in CAD magazines always list one of the biggest faults of Revit as the lack of an API. If program designers do their job, and Revit designers have done a great job so far, there shouldn’t be any reason to have an API. My question is, who really wants an API? My guess is that it is not Revit users but CAD developers trying to make a buck. If AutoDesk were to open up Revit’s API it would most certainly be a bad sign of things to come. It would essentially mean that AutoDesk is circling the wagons and trying to maximize profits by cutting down on Revit development and letting outside programmers fill the void. Look at what AutoDesk did with the AutoCAD’s “Express Tools”. They started charging extra for tools and features that should have been include in AutoCAD to begin with. If Revit opens up the API, Revit users will definitely lose out and the Revit program will suffer for it.

[Allen Lacy]

I agree with Steve & Scott (and by the looks of early returns, so do other Revit users). Why do I want to pay more for add-on programs that should be in the software to begin with? I'm not a programmer and don't want to be! I'm an architect that wants a complete software package, and so far, Revit it doing its best to fullfill that.

[Simon.Whitbread]

Agreements all round ... at the moment.
I've been an AutoCAD user since rel.10 and although not a 'programmer' I can still create useful lisp routines for this and that. As Allen says, why pay more? I still have to support lisp blah blah blah, but haven't missed this function yet. Come to think of it, I have not missed Layers either! There are a few little things that bug me... like not having profiles, so I have to path each machine individually. That and I want to be able to have a variable level view plane. But on the whole its a good programme, Can't wait to start rolling it out after our R+D stage

Just found the REVIT.INI file!! One less thing to worry about

[J-G]

I agree with all. I think the major concern would be as Scott wrote, with an open API the probability would be that features that should be in Revit would be left for add-on products. Have you ever looked into ArchiCAD? They have the base program, but then there are a dozen add-ons to buy. "If you want to do this buy this"....it continues on forever. Leave it the way that it is, and let the Revit team do what they do. They have already created an amazing program and seem to be very interested in customer input.

[JamesVan]

Some professionals I've spoken to have balked at the idea of not having a programming interface. I completely agree with Steve on the premise of becoming an Architect once again!! :D However, some have argued that the playing field has become too level..."tastes just like homemade, but no lumps!"

I'd rather spend my days helping my project teams create their buildings than automating the door schedule with endless lisps, but if I have an innovative idea for something in Revit (I've only come up with 2 or 3 unique cases) then I'd like to have some way of accomplishing that. Maybe it's not an entirely open API, but a macro recorder or something of that nature.

[Vincent Valentijn]

Since this post is a reaction to the discussion I was having on alt.cad.revit... I'd like to post most parts of that here for those who don't know the arguments yet; It all started out with my statement -...[give us API please!!] -


Greg Cashen:Here's my vote for NO API!! Please do not make us pay others for what Autodesk has so thoughtfully provided us for a very hefty sum! Seriously, I do not like the idea of an open API if it means we have to pay for every 3rd party developers tool to do what right now Autodesk and the Revit team are doing as part of our purchase.


Judging from the reactions here.. most of you probably agree with this?


Me said [edited, I was a bit rude at some points, sorry for that Greg]:Boy.. that's like being extremely short-sighted.. Without any API the development of Revit will go -a LOT- slower. Probably as slow as that ther similar CAD sofware will soon supply much better performances. For you, the Reviteer, that means a loss of investment since your associates and clients will end up using other software.. file-formats etc..
~ Besides, your argument that you are -paying- for this is nonsense. How do you think can apply to get the API ?? If you are not a member of Autodesk Development Network you won't get it. In fact, we pay for being part of ADN and we think we've got the right to an API since that's why we pay our memberfee in the first place.
And an open [free] API wouldn't be that much different.. we are the ones that invest our time and money into developing 'tools'.. not you. Besides, an API won't be too hard to develop since... [] a free API is probably even better to help a good steady development of the software along.
The idea we're going to make tools that you will need to pay for is so far off... If we don't sell you our tools, you won't pay, simple as that. In fact, it will do you much good. If you look at AutoCAD.. for which API is available for years already, you see that the best little tools [like from bonus-tools] end up being integrated - you haven't payed for them.. still you will finally profit from our ideas.
so .. please think before you shout, the API won't harm you, it will help us, Revit and.. you too.

So you see.. I'm very much for an API and not just because we're into that business

Then Jeffrey McGrew sheds his bright light on the discussion:

While I think that we can all agree with you on the value of an API, I just wanted to shead maybe a little light on this whole thing. When I was talking with the developers at the 6.0 feature meeting that they held out here on the west coast, we started talking about an API. I think one of the main reasons that the Revit team is leary of opening up the API comes back to two main reasons: Simplitiy of the software and quality of the software.
In regards to the first issue, I think they really want Revit to be the best software for the AEC community ever, and as such, want for user's needs to be served by 'native' tools rather than an API. Rather than going down AutoCAD's road of being all things to all people (and thierfore being nothing to no-one) they really want to know what it is that you want to do with the software that would need an API, for that need might be better served with a 'native' tool or represent a design flaw in the software itself.
They (correctly, I feel) see that forcing the user's to customize the software to make it useable, while being the current accepted way of the CAD world, doesn't pay off in the end for the user's and creates as many problems as it can solve. I don't think they are anti-API, but rather want to know what it is that you want to do.
This leads me to the next thing, which is quality. AutoCAD's a mess. It's great for what it does, but it's a mess. So many different tools written so many different ways by so many different people, the 'express' tool add-ons in-again-out-again, third-party tools written by doubous-quality coders, Three (THREE!) different computer language API's, lots of propritary add-ons, the same code carried from version to verson without being fixed. All of that adds up over time. WE HAVE CONSTANT PROBLEMS WITH CONSULATANT'S FILES because of all of this. Every new version of AutoCAD that comes out also breaks a lot of these add-ons, requiring them to be re-written, over and over; a HUGE waste of money for the users. It took us two years to fully migrate from R14 to 2000; now 2004 is out and we don't want to re-write everything yet AGAIN. So I think that the Revit team really want the software to be high-quality, to simply work; and as such, don't want it muddled with poorly-written or in-house API add-ons like AutoCAD is.
Opening an API to the world, ala AutoCAD, isn't the best solution IMHO. Doing something more like PhotoShop did with it's API would make a lot more sense. Keep in mind all of the above is just my opinion, and doesn't reflect anything about the Revit developers. It's just my feelings of what's going on from talking with them. So we'll see an API eventually,
I'm ceratin, but it might not be in the same for as AutoCAD, and I for one think that's a REALLY GOOD THING.


So Jeffrey agrees on having the API.. but also expresses the fears of development that it might compromise simplicity and quality.
IMHO though this only depends on the type of API they choose to launch.

Greg stated:
[] I like the fact that the Revit development team is focused on what we want. I think an open API would change that. [and also reminding me not to get insultive in the heat of discussion :oops: ]


which is a pretty good argument.. though I think that anyone developing through API will definately be just as focussed on what users want, they need to sell their ideas just as well right?

some more light from Jeffrey:
Well, in terms of a commerical closed source product, I feel it's a bad thing. This is due to the fact that, just as you state with your structural example, the product developer can offset the developement costs onto the users while reaping the benifits. Also I feel that, with closed source commercial software, the fact that any part of the deal can change at any time (thus negating any in-house
work you might have done) render it as not a good platform to 'build'
your own application on top of.
However, in an open source software, this is reversed. For then any developements you may make to the software that aid your work can be released back to all the users, and can be extended upon by them and come back to you. Also, the software 'deal' is much more stable, for the software you've spent a ton of time learning and extending isn't going to be suddenly discontinued for reasons that have nothing to do with your work (see the fiasco of Lightscape->Viz 4->Max 6).
What I think might be the best option for an API is something like MacroMedia or Adobe's approach, where there are two levels of API; one's a macro level that just lets you script functions, and another that's a plug-in level that requires professional programming experance and the purchase of a developer pack. But neither lets you change the fundamental functions of the software, so that the base tools remain the same no matter what add-ons you might have. But this is just my opinion, and I'm not a software developer.

This morning I found the discussion and added a final post:

Ah, nice ;) this is what I call a discussion with good arguments. I think we actually agree for a good part, for I am a big fan of the way MacroMedia handles their productdevelopment. [Amazingly they have even managed to have better drawingtools in FlashMX than a lot of CAD software out there btw.]
The jungle that is AutoCad.. I must admit that's true. But also, I kinda like the idea of being able to make stuff custom (I simply ignore all the **** that I don't use)... For things being customised, or open for add-on or anything it's not necesessarily a mess things up though.. which brings me to FlashMX again. I just love action-scripting and it also has great plug-ins [like Greg mentions]
But.. back to REVIT's API I too think that an API should be open-source.. that way any interesting adjustments could come back to the Revit Development team, than they can evaluate and see if they want to implement any functions/adjustments it might have. This means that a 'simple' user will get all his money's worth [development won't stop] and it enables advanced users to customise for specific clients [as we do].
Alternitively an API should allow for gripping all 'handles' so that we can build plug-ins... But honestly, around here the suspicion is growing that Revit is in fact pretty messy internaly allready, judging from it's performance [is that why we're not allowed to have a look?]. Even something that should be straight forward and clearly structured like family production allows for multiple methods with uncertain results.. some functions like grouping don't seem to work most of the time.. not to mention the total lack of hyrarchy [external] < [i]insert :twisted: a bit harsh maybe I admit but such things do make me wonder how 'solid' Revit really is>
In this area; As Greg stated and which I've repeatedly been told by RDT, they want to develop by means of following the practical use. That's a good thing I do believe [some very good people of the development team convinced me], but it hurts me to see such approach closing all kinds of functionality along the way.. this is simply clear by the shear amount of so called -work arounds- most Reviteers have invented. Specially when decissions that users need to control are made -for them- my stomach rolls.. it's something like telling an Acad user,'Sorry, you only get 10 layers and we decide for you what you can put into them..'
Trying to follow practical use without overshooting it's goal is a very delicate process I think.. specially if you take into consideration that the
building-industry is very diverse, specially on a global scale. This post right sound a bit negative but let me assure you - I love Revit! - and this comment is ment to make it even better. I know there are some greatly talented people at Revit Development <yes I'm sucking up ;) but it's true> and I hope.. think that they will eventually get Revit to become 'mature' at some point. Having an API could help I think and I hope it will come soon .. open source could turn out to be a savior instead of a burden. It could allow us to join forces, there might be some great ideas out there.


So.. now that you've all 'caught up' to the discussion [if you bother to read it all]. I would really like to know how you guys feel about all of this.
Let me form another question: API is coming [at least Revit has promised this a long time ago allready] but what kind of API would be good for Revit.. and for us?

[Steve_Stafford]

I find myself "wishing" for a macro recorder of steps: do this, do that, then this then that...do it over again till done.

Sheduling flexibility to calculate data based on disparate but interelated parts of the building: IE: Glazing and room area...code dictates specific values are required, the data is in there I just need a way to use both to respond to the code issue, and put it on a sheet. And boy is that task tedious.

Until we can shift the paradigm in Architecture/Construction that seems to think large bodies of text (schedules) are better on a sheet produced by CADD instead of by a word processor and included in a specification document we have to be able to put data on a drawing sheet. (assuming anyone wants that beside me)

Neither item needs an API I can manipulate and ideally I won't need to, but I wouldn't have to "wait" till the Revit team can get to it...if it makes the cut!

Workarounds abound in every software, so to characterize them as excessive or unacceptable or unreasonable is a bit off. Strangely enough, I find it easy to accept what doesn't "work" because the team is SO receptive to ideas and participates in the solutions to issues till implementation/repair is possible.

[Martin P]

I cant say that I am particularly worried by it. Autolisp is NOT something you have to know anything about to use autocad, you can use it out of the box... I dont see a problem with API from a users point, either learn it or not its up to you - something fairly basic and simple would be nice for users to help speed things up a little sometimes. The thing I dont understand are third party developers, with Autocad there are many disciplines using the software so it is not possible to have everything they all need. The fundamental point to using Revit is that it is geared towards Architecture, I would be very annoyed if we had to buy stuff to do for example complex stairs, that should be something it can handle. I just cannot see what exactly these third party developers could be developing that wouldnt be expected by users just to come with Revit in the next release, I dont think they could really make any money could they?? Familes are about as far I can see it working, maybe they will end up being able to make them "load only" or something ie you cant go in and edit or see how it is done, surely that is the only scope for third party developers - unless they start gearing Revit towards other disciplines, but who is going buy Revit, then have to buy a load of plug ins for it when there are already systems out there for other disciplines?

[Vincent Valentijn]

For us it's quite simple. We'd like all kinds of data that is not available at the moment.. and we want to be able to handle this data in a better way.

We have issued the specific needs we have to development but it's no fun to sit around and wait -if- and -when- we get what we want. Alternatively we requested to do things ourselves, for that we'd need an API.. but we don't get that either it seems :?

It might sound like a simple case of impatience but.. for business a little wait could cost us a lot. If at least Revit was open for just a little more customisation it would help enormously. Also, personally.. I'd love to have my own family-categories and stuff like that.

[Phil Palmer]

API is going to come whether we like it or not.

I believe it will be needed (eventually) when the BIM scenario is truly realised in REVIT.
An API will be needed to interface with other programmes for Analysis and design software.

BUT - Lets get the product to that level first before opening up that can of worms

[gregcashen]

To reiterate, I do not support an open API because I do not want Revit to stop, slow or transfer Revit development to 3rd parties. I understand v's point, but I disagree. I do not think that Revit lends itself to an open API. It is not a platform, it is a very specific tool. Imagine, since Revit is not a structural analysis or steel detailing tool, if they opened up the API, it is conceivable that Tekla or someone would come along and offer to develop the steel design/detailing plug-in for Revit. Now, instead of us waiting for Revit to announce that they will be improving their structural tools in 6, we must wait for Tekla to create the plug-in, which will take longer since they do not have the native Revit knowledge that the Revit development team does. Additionally, they will have to train testers and perform tests. What if Revit 7 is scheduled to come out by then...well, Revit will have a release agreement with their developer network which states when Revit can release a major upgrade and what it can include. So suddenly, functionality I expected from Revit for my $4000+subscription fee (or whatever) is going to cost me $5,000 from another vendor, is going to take longer to be released, is going to be supported by another, less knowledgeable vendor and most importantly, is going to seriously impact the development/release schedule and core functionality of Revit.

That said, I do support the following:
1) Let's have the ability to record/run macros which would allow us to do simple scripting of repetitive tasks, such as setting up our drawings, creating our default schedules, applying materials to objects, etc. If I could write a script that would allow me to turn on/off visibilty of categories that would help my workflow tremendously.
2) Allow for greater interaction with the program database within Revit. I would love to be able to run SQL queries on the database from within Revit projects and families and use results to update families, schedules...even building layout??. Even if it just allowed me to store the results of the queries in a new view type (call it a Calculation View). Combine this with logical operators, if...then statements and the like... then I could automatically generate ventilation areas, shearwall sizes or whatever and include that in a single file with the drawings. You can figure out your own uses for this. :)
3) Allow me to customize my workspace like the macromedia or adobe tools. I would love to be able to dock the palettes I use most and hide others, add and remove toolbars, heck, combine it with number 1 above and I could create new buttons that do my favorite things all at once!

In short, give me the flexibility to customize my revit experience and interact with my model more without charging me more for it and I would be a happy Reviteer!

[PeterJ]

The 'm' word has come up repeatedly in this discussion. Yes, 'maturity'.

At release 5.1 the software is still improving in a fashion that demonstrates that the developers do not think the product has reached the end of its primary development phase. We are still seeing pretty fundamental new tools coming through in recent releases, such as hosted sweeps, vertical compound walls and so on. We are also assured that the twice a year product release cycle is something they are keen to adhere to and this again suggests to me at least that they know the product is not fully mature.

That said we are at a point where the pace of development and the maturity of the software are begiinning to settle, thus in release 6 we are assured of a much improved stair tool, for example. It's well known that the stair tool needs work,but the fact that the software has reached a point where it has sufficient features that major improvements are being sought for some of the existing tools demonstrates that the development flow can begin to slow and workability issues be addressed at each release.

The preamble aside I think it is inevitable that we will see an API at some point but not before Autodesk have made significant investigation into what needs to be delivered. The nature of Revit's development has been, it seems, one of careful analysis of workflow and need, hence the constant requests for examples where specific functionality has been sought. I think the majority of things in here that people are asking for may very well be deliverable as integrated tools and becasue they may respond to many more examples than the users here have identified may come in fashions you don't expect but will find will give what you need. A full API is unlikely, in my view, until such point as the software reaches a level of maturity that greater market uptake demands and then perhaps specialist applications might be appropriate.

It's not there yet.

[Wes Macaulay]

If Revit were to ever open up an API, I would want it be so people could develop their own tools to manipulate Revit's database, create their own tools, etc. Sure we want the Revit team to develop all the tools, but if it could be possible for someone else to dream up their own creative gadgets, why not? Just like people came up with a dialog box interface for managing xrefs in AutoCAD R12... we didn't see that in AutoCAD until R13. I admit that it's hard to stay ahead of the curve with the guys from Revit, but it would be nice to experiment a bit!

I want Revit to forever maintain its capabilities so that we have little need of outside tools. I am open, however, to others being able to build the tools they want to add to Revit's wide suite of present tools. It has a bit of the idea of turning Revit into more of an open-source thing for everyone's collective benefit.

[gregcashen]

API is going to come whether we like it or not.

I believe it will be needed (eventually) when the BIM scenario is truly realised in REVIT.
An API will be needed to interface with other programmes for Analysis and design software.

BUT - Lets get the product to that level first before opening up that can of worms

I think at this point that there needs to be some discussion as to what an API and an open API is. Forgive me for stating (or possibly mistating :oops: ) the obvious...and feel free to correct!

API stands for Application Program(ming) Interface. There are 3 basic ways outsiders can interact with a program's API:

1) Many companies, when interoperability and other issues arise, allow 3rd party developers access to their API in order to make sure that their programs will interact properly for data transfer, etc. This is usually a very tightly controlled process.

2) Other companies actually license their API to developers within their developer network, allow them to write plug-ins and 3rd party programs that can interact with their programs and allow them to sell their products as Photoshop (for instance) plugins.

3) Still other companies completely open the API to anyone by integrating it with Visual Basic (VBA) or other programming languages and tools that provide a means of accessing the internal structure of the program. These companies can open the whole API (very rarely done) or simply a subset of functionality. Then you and I can write VBA scripts or macros or even connectors that allow us to interact with data between programs. For instance, one could write a program that would pull information from a structural analysis program's model and rebuild the model in Revit.

I guess we need to be clear about what level of open API is desired or not. For my part, I do not want the 3rd choice...a completely open API that anyone can write code for (good or bad).

I also am not too keen on the second choice, as I think it will degrade the quality of Revit coding/functionality. I am for the first type, which allows other companies to create connectors to Revit so that their programs will be interoperable with Revit. But in terms of what functions are implemented in Revit, I want Revit to be in charge of that...based on our input.

Anything other than that will, I think, lead to Archicad world, where you need the base tool, another tool for plotting, another for stairs, another for rendering, another for estimating, another for really good stairs, another for super rendering....Forget it.

Revit's power is in it's simplicity and I prefer it that way.

:roll:

End of rant :wink:

[Vincent Valentijn]

I think at this point that there needs to be some discussion as to what an API and an open API is. {} There are 3 basic ways outsiders can interact with a program's API:
1) API in order to make sure that their programs will interact properly for data transfer, etc. This is usually a very tightly controlled process.
2) plug-ins and 3rd party programs that can interact.
3) open the API to anyone with VB.


I think you're pretty to the point with these 3 points.. :roll: except maybe the useage of VB. -Using VB doesn't automatically mean that you can control any part of the source-code of a software, in fact, it's very very rare that a sourcecode really becomes available to 3rd parties.
So maybe point 3 should state: open up the source with/for API
Since even for point 1 an API could be accessable through VB.. If you look at Revit's mature < :idea: > mechanical brother Inventor, you can see what I mean. Inventor can fully interact through VB.
This means we can run complex macro's, control parameters from the outside, read parameters to directly control the production-machines etc.. but this does not mean we can change anything inside the software or even add any more functions [just create macro's.. like writing a multiple trim for ACAD in lisp] - now this kind of control is the kind of API I'm talking about, it is the most common way.
In your 3 points it would be point 1 with a tendency to point 2 :roll:
The company where I work is a true millipod..multi-expertise.. Adesk reseller for education, training institute, CAD to CAM specialists, interface and system designers.. and more. For instance the CAM sector could be immensely interesting to all of us. Emagine sending your RVT files to suppliers, they hook things up to their machines [which we write postprocessors for] and your roofs and windows rolls out on the other end! Pushing down production cost - allowing you architects to design a little more for a little less money. And .. this is just an idea I just thought up.. there are many more reasons why it would be nice to be able to handle data coming from Revit a little bit better, preferably a 2-way stream.
anyway - you get the picture..
It is not in any way our goal to take over any sort of development that should or could be part of the normal Revit software, we're just finding ways to connect to it and take it into other dimensions. These are not user applications but mostly solutions for the industry to handle your products in the best possible way.
Currently we're into a Revit based tool for building-maintenance companies, a first reconnesance to have a look.. that immediately made us bump into the extremely closed box without enough handles on the outside that Revit is now.
So.. we are -not- interested in making some sort of plugin or adding specific user oriented functionality.. we're not rowing in Revit's water.
But now I'm gonna stop this post before I go and spill all the beans here ;)
Hope you can now see where I'm coming from, we're all on the same team here.

[Martin P]

option 2 watered down could come up with some really useful tools, for example there is that cost estimating thing that you can get with Revit at the moment, it only works in North America I think? I havent really used it. But I can imagine somebody coming up with something specifically for the UK (or Netherlands or wherever else), I cant really see Autodesk investing too much time in this type of thing other than for the U.S Market. I think this is maybe the type of the Vincent is talking about? But I would hate to see stair tools etc being produced - if the could open it up to the point where scheduling, databases etc were availiable to be altered that could only produce good results I think.

[Vincent Valentijn]

you get the picture Martin.. we wouldn't produce a tool to drawup chairs or stairs, we'd only work with the stuff you would draw in the normal Revit way.. to actually produce the chair. No need for a plugin or anything, it's just the manufacturer that has bought a postprocessor to 'translate' your drawing to manage the machine. 8)

[beegee]

Interesting Vincent.

Have you got a "hit list" you're prepared to share ? ( Nothing proprietary in-confidence of course, just broad brush. )

You'd be focusing on the Euro market .... right ?

[Vincent Valentijn]

Interesting Vincent.

Have you got a "hit list" you're prepared to share ? ( Nothing proprietary in-confidence of course, just broad brush. )

You'd be focusing on the Euro market .... right ?

:shock:

[beegee]

.. we're partially related to an Australian company :? isn't that something ?

Well how much can a koala bear ?

[Michael Coviello]

:D I am in favor of an API. There have been many routines that i've written in autocad using VBA and also Lisp. For the most part, a simple macro language within revit would be adequate. I've extensively used the "cross-application" ability of VBA in word/excel/microsoft access etc., so when I learned that Autodesk introduced VBA in v14.01 i jumped right in with great hopes. I admit there are a handful of routines that i've made in autocad which need to go outside of the application but VBA is a language which can be used either way and it is so prevelant(as a programming language).
If many people agree that Revit needs a "macro recorder" why not employ VBA? It is everything that a macro recorder is an a lot more. Plus we all won't need to learn a new language (revit lisp or what ever it may be called)
It seems like i'm outnumbered but I am in favor of it. These are processes that save hours upon hours of time not to mention repetitive tasks that no one wants to do. For example. Many products like kohler have cutsheets in dxf format. I made a routine which opens them then saves as dwg. It operates on a directory and all subdirectories. Hundreds of dxf files were converted while i was at lunch! Automation makes tasks like this so simple.
:D

[aaronrumple]

Revit needs several 'API's'...

The first thing it needs is not an API, but a scripting language to make families smarter. What they did in ADT 2004 with the VBSripting inside the schedules would be great to have in Revit and I'd like to see it also be useable in the family formulas.

This would do probably 90% of the automation I want to do right now inside Revit.

As for the API, the first version should be one that lets developers USE Revit information real time from a BIM. But it should not allow 3rd parties to develop tools inside Revit. It should also be based on a modern language. Either .NET or Java <and I'll let the two camps argue over that>. VBA is the only other logical choice, but .NET will allow for a true collaboration tools which communicate well over the net or a netowrk.

[aaronrumple]

....one more.

While I want the Revit model to only be modifiable with the Revit UI, I would like an API for creating families.

The family editor can be daunting for a new user and I think that 3rd Party evelopers could make simpler UI's for family setup.

Companies like Pella, Anderson, Steelcase could then have a app that builds custom windows or funiture from the 'rules' within which company can manufacture.

In fact our company is working on just such an app for another window company to be use in AutoCAD.

[gregcashen]

I like your thinking Aaron. This would give us the most fuctionality and flexibility without inadvertantly subbing development out to third parties.

[Vincent Valentijn]

You're coming from a similar place Aaron.. I like your summary.
For us VB would be nice (also Java.. but I somehow really dislike it myself) but we're also into .NET and that would definately have my preference.

[MikeJarosz]

I voted FOR a Revit API. Many of the responses to this topic indicated they wanted the ideal CAD program to be fully integrated and developed by the original software authors. ACAD is an incredibly feeble program, but AutoDesk wants it that way. How many releases did it take before there was a native command to switch text case?

Our IT department visited AutoDesk in Sausalito YEARS ago, with a list of features we thought they should have. (Our IT people by the way, were graduates of the Cornell and Carnegie Mellon computer graphics departments.)

AutoDesk told us we were crazy. With 90%+ of the market, their only option is to sell upgrades. If they were to put every known CAD tool into the next version of ACAD, they would have no future. GM calls this planned obsolesence.

So what do you do when your needs conflict with their corporate stategy?You have to provide your own solution. That's where the API comes in. I don't believe it is possible for a CAD software firm like AutoDesk to anticipate every conceivable requirement a client might have. And even if they do, it might not be cost effective for them to provide it, if they anticipate selling only three copies. And do you want to learn a huge program that has the ability to design space shuttles and nuke submarines and a three bedroom house?

As an example, in our very large firm, it is not unusual for a project to have thousands of drawings. With software we wrote in house, I can easily plot 1000 sheets in one day, without help. We cannot have a CAD system that cannot do this.

This would not have been possible in ACAD without a programming interface. (I use VBA)

Some of the responses note that an API would only be of use to third party developers who are making up for deficiencies in the base program.
But don't loose sight of the fact that REVIT is already an architect's dream come true. It's in an entirely different league than ACAD. And it's still in development. When REVIT was in it's early stages (the Dessault phase), they came to us to present their efforts. They pointed out that you could call them with a deficiency and they would alter the code then and there. They even brought a programmer with them! (Mark, are you listening?) I found the original team to be very responsive to suggestions. I hope they haven't lost too many of them. Judging by the responses coming from Waltham, they're still out there.

I hope the rumors (there are always rumors) that ACAD bought REVIT to kill it are untrue. But I also hope that they don't keep it and turn it into mush.

[Melarch]

I have read through all of your threads and I tend to agree with the NO API now contributors and for many of the same rational they offer. But there one reason that have yet been put forward.

To date Autodesk in acquiring and mission statement to develop Autodesk Revit has focused on their interest to internally develop a more complete AEC solution to provide both the initial project development architectural and engineering team, the construction management and building team and ultimately the building owners and management a single building model with features and tools to enable cradle to grave management of the building information. This is evident from Autodesk's commitment to create or integrate a set of building modules as currently available for ADT and further develop a more robust structural module for Autodesk Revit. Autodesk's initial drive to devlop these add-on modules is to bring Revit up to par with ADT to permit the multidiscipline engineering firms and those architectural practices who have encouraged their consulting engineers to invest in the building modules in order to better coordinate construction plan development and coordination of architectural, mechanical, plumbing and electrical data.

It would seem Autodesk has a self-serving goal with Revit's lack of API, in that they can develop, market and reap the financial rewards from new releases free from competition of 3rd party developers to deliver new features and tools at a faster product release cycle and add-on program modules. But I agree that letting Autodesk control the development Revit and the integration of new program modules, the users can and will benefit.

But I would like to see some opportunity, whether in the form of an API, or better internal tools designed to customize the interface, menus and, extend our ability to create system elements/components that possess all of the characteristics of their equivalent system types. Not as the current limitations that In-Place Families create for walls, floors and roofs.

[gpuerini]

Mark me down as a definate "YES"!
Having a programming background, I find it extremely frustration not being able to run even the simplist script routine.

Also, the residential building companies I've been with have a signifigant investment in "in-house" functions. They would be reluctant to make a switch to a software that doesn't even offer the possiblity of recreating these.

[Steve_Stafford]

...to run even the simplist script routine.

Such as...?

The developers and product managers need insight into specifics to determine whether a wish is solved with an API or by providing better tools. "Most" users would rather not be programmers I suspect, at least that's true for the architects I know.

I enjoy the freedom from programming that Revit offers. I also appreciate the fact that the Revit team is really dedicated to providing comprehensive tools for the tasks that architects do. And I trust for our fellow engineers soon too.

Regardless, an API is in our future, when remains to be seen. I just hope it doesn't distract the team from providing tools and features in favor of providing a way for users to do that work instead...ala the others.

[robmorfin]

Don't open the API, use the opened API's from other software to bring all kinds of objects and information and to be able to Export or link to other formats or software..

Examples:

Nurbs cannot be made in Revit, if imported as DWG or DXF nurbs are deformed to Faces, IGES is the best format to transport Nurbs without losing it's properties.

Virtual Reality models cannot be exported, therefore they cannot be shared on the internet w/ textures so anybody can navigate in the model, a VRML export (.wrl or .mov) could make this work (Accurender for AutoCAD includes this export without bringing textures)

AutoCAD's API is open, give them (or yourselves, it's the same company now) the tools to link Revit Models to a Drawing.

Perfectly Spherical Maps are made as .HDR files for use with the renderings, MAX, Maya, Lightwave, etc can use them, make that import function.

Tools to share and interact w/ sketchup, piranesi, autocad, Viz, MAx, Maya, Lightwave, etc. are out there available for Revit to implement.


Again, don't open the API, please, BUT let us use the tools not available in Revit, or sometimes available but it's easier to do in other program.

[gregcashen]

I think that this thread has brought a lot of lively debate out into the open, but it doesn't seem to have brought out much info from the factory...

My feeling is that Revit's direction is more geared toward giving selected members of the ADN (Autodesk Developer's Network) access to an API to exchange data with Revit. I can see something like this used to facilitate data interchange between structural, mechanical, energy, rendering and presentation software without opening the API in a general sort of way.

It would be interesting to hear from someone "official" what the API plans smell like at this point. I know a lot of that is under wraps, but maybe someone can get authorization to just give us a general sense that, for instance, "Revit 7 will allow selected member of the ADN to access the API for the purposes of developing energy analysis tools."

Something...anything...