Nice set of questions.
1/ Is this API in ProIV (I assume so but I didn't actually see anyone say so)?
Yes but we do have other options for 'C' based access.
2/ Assuming the API is expressed in ProIV, what form will it take. For example will it be global logics, callable functions, kernel LINK calls or even maybe bus/task based?
Probably global function published interface (performance should not be too bad with the proposed function caching)
3/ Will I be able to use the API if I should choose to stick with an older development environment for a while or will it only be usable within VIP?
4/ What database are the bootstraps stored in for v5 and is there any choice about this?
The initial release will be based on Pro-isam
5/ What will the performance of the API be compared to the bootstrap access we use today?
It will be slower but is this really and issue? if a bulk change or scan takes longer the fact that you can still do it is what is important. We will keep in mind the overhead during design.
6/ Will v5 be available without VIP or is it a prerequisite (I imagine this is well-understood but I've obviously missed it somewhere)?
Yes v5.0 will be released in September minus VIP which will still be in trial until October/November.
7/ Will the API ONLY be available WITH VIP (I'm not clear if that was implied or not)?
Yes as the API is for the VIP boostraps. For version 5.0 existing native boostraps will still exist and be accessible using standard definitions. (Version 5.0 extensions will not be published for version 5.0)
8/ Is VIP going to be a chargeable product (or is this still with the bookmakers)?
Hey that's commercial (I'm techo)
My understanding is that VIP will be free as part of V5.0 for which there will be an upgrade fee.
9/ What organization do the 'HRS' team developing this API actually work for?
HRS are a Northgate division
10/ Will the API be available free of charge or will it be viewed as a product itself?
It will be shipped as part of VIP maybe with some restrictions (not sure on this)
11/ Are ProIV committing to always make an up-to-date API (ie: including all 'boot extensions') available in production at the same time as new releases of kernel/VIP are introduced?
Yes where appropriate some extensions may be process triggers and not straight data writes
12/ Am I correct in thinking existing tools using traditional bootstrap access will NOT work with v5 EVEN if you continued to use only the traditional development environment(s)? In other words, all tools MUST be rewritten to use the API?
No they will work on native (non VIP source) but will cause
potential corruption if used against VIP generated native boots. Version 5.0 will be based on native boots and these will not become extinct until a later time.
-
This topic is locked
35 replies to this topic
#32
jcduym
-
- Members
-
- 35 posts
Member
Posted 12 July 2001 - 01:52 PM
Thanks to Neil for the effort to answer the points raised by Richard.
Several points of interest:
1. Why no answer on question 2? An oversight?
2. Are we slowly being softened to accept the fact that version 5 is slower? A lot (because otherwise it would not really be necessary to gently bring this to us)? And yes: it will be an issue if this is slower. Not many developers are prepared to wait any long than strictly necessary for a scan or whatever to complete. They will write their own utility to do it faster if they can. Native. And wasn't VIP supposed to be all we would be requiring in an environment?
3. What is the use of releasing version 5 without VIP? I understand from the discussion that version 5 is only an extension to support version 5. Which we will not be able to use. What other advantages will this new kernel be giving us?
4. The last remark is slightly disconcerting: 'Version 5.0 will be based on native boots and_these_will_not_become_extinct_until_a_later_time.' When? When we all have grudgingly converted our applications to version 5, so there is no way back?
I am getting more and more interested in seeing what VIP will be like though!
Cheers
Several points of interest:
1. Why no answer on question 2? An oversight?
2. Are we slowly being softened to accept the fact that version 5 is slower? A lot (because otherwise it would not really be necessary to gently bring this to us)? And yes: it will be an issue if this is slower. Not many developers are prepared to wait any long than strictly necessary for a scan or whatever to complete. They will write their own utility to do it faster if they can. Native. And wasn't VIP supposed to be all we would be requiring in an environment?
3. What is the use of releasing version 5 without VIP? I understand from the discussion that version 5 is only an extension to support version 5. Which we will not be able to use. What other advantages will this new kernel be giving us?
4. The last remark is slightly disconcerting: 'Version 5.0 will be based on native boots and_these_will_not_become_extinct_until_a_later_time.' When? When we all have grudgingly converted our applications to version 5, so there is no way back?
I am getting more and more interested in seeing what VIP will be like though!
Cheers
#33
Richard Bassett
-
- Members
-
- 701 posts
ProIV Guru
- Gender:Not Telling
- Location:Rural France
Posted 12 July 2001 - 03:56 PM
Admirably clear Neil -thanks.
Neil did answer question 2. Question 3 was not answered but probably because the answer is pretty clear from the reply to question 7.
Neil did not say version 5 overall was slower, only that access to source code via the API would be slower than we have been used to via the bootstrap filedefs.
The key question is HOW MUCH SLOWER! For example twice as slow I could live with, an order of magnitude slower I would be pretty unhappy about.
Neil did answer question 2. Question 3 was not answered but probably because the answer is pretty clear from the reply to question 7.
Neil did not say version 5 overall was slower, only that access to source code via the API would be slower than we have been used to via the bootstrap filedefs.
The key question is HOW MUCH SLOWER! For example twice as slow I could live with, an order of magnitude slower I would be pretty unhappy about.
Nothing's as simple as you think
#34
Guest_Neil Mellis_*
Guest_Neil Mellis_*
-
- Guests
Posted 13 July 2001 - 09:12 AM
Don't know where the answer ended up (bad paste)
3/ Will I be able to use the API if I should choose to stick with an older development environment for a while or will it only be usable within VIP?
The API will be for the VIP source abstration only not native. If you wish to use your existing tools but without
access to the new extensions they should work (post regen against v5.0 native bootstraps)
How much slower :- don't know as we haven't written the code
yet but we will be very concious of performance as well as access functionality in design. In theory the overhead of basic writes/reads should only be the function load time plus any additional dependency processes triggered. With the planned function caching kenel feature this should be pretty fast as the load will be from memory.
3/ Will I be able to use the API if I should choose to stick with an older development environment for a while or will it only be usable within VIP?
The API will be for the VIP source abstration only not native. If you wish to use your existing tools but without
access to the new extensions they should work (post regen against v5.0 native bootstraps)
How much slower :- don't know as we haven't written the code
yet but we will be very concious of performance as well as access functionality in design. In theory the overhead of basic writes/reads should only be the function load time plus any additional dependency processes triggered. With the planned function caching kenel feature this should be pretty fast as the load will be from memory.
#35
Guest_Neil Mellis_*
Guest_Neil Mellis_*
-
- Guests
Posted 13 July 2001 - 08:28 PM
Not hand picked but our biggest customers that pay us the most money after all we are a business and respond to our market needs.
The reason for entering into this dialogue is to listen to opinion of individuals who have valuable input into what we are doing/trying to do.
I fully admit that some developers/sites do not like change but we (PROIV) have to change both our technology and approach to our customers otherwise we will not survive in a very competitive arena. As I have said many times before VIP will form a framework that will enable us to embrace a number of new technologies and potential earn us new business. For those maintaining legacy green screen apps VIP will not provide added functionality over new Kernel features but it could improve your ability to maintain an application. It's up to people like your self to make sure that it fulfills this requirement. The API approach to code access is an important part of this and we need to make sure that you can still develop the sort of tools you need.
Many (not all) tools that are written can be attributed to lack of functionality in the development environment. Why not add the tool to the environment where it belongs? I have worked on many sites all have their own logic editors search and replace source code control etc written again and again by local developers. If the tools existed within the development environment you would not have to write them and could concentrate on your business requirements which is to develop and maintain business applications
The reason for entering into this dialogue is to listen to opinion of individuals who have valuable input into what we are doing/trying to do.
I fully admit that some developers/sites do not like change but we (PROIV) have to change both our technology and approach to our customers otherwise we will not survive in a very competitive arena. As I have said many times before VIP will form a framework that will enable us to embrace a number of new technologies and potential earn us new business. For those maintaining legacy green screen apps VIP will not provide added functionality over new Kernel features but it could improve your ability to maintain an application. It's up to people like your self to make sure that it fulfills this requirement. The API approach to code access is an important part of this and we need to make sure that you can still develop the sort of tools you need.
Many (not all) tools that are written can be attributed to lack of functionality in the development environment. Why not add the tool to the environment where it belongs? I have worked on many sites all have their own logic editors search and replace source code control etc written again and again by local developers. If the tools existed within the development environment you would not have to write them and could concentrate on your business requirements which is to develop and maintain business applications
#36
Joseph Serra
-
- Members
-
- 93 posts
Advanced
- Gender:Male
- Location:Melbourne, Australia
Posted 16 July 2001 - 08:10 AM
Have you been asking companies with large run time or development licenses? This topic principally covers development. I trust you have been concentrating on the your customers with a large number of development licences.
Since you have entered into this dialogue, it does appear that you have NOT been listening. Just read through the posts. Look at the figures. Believe it or not this site brings together more than 300 developers (figures based on the names database). So I would have thought, you would be paying close attention to what people are saying here.
This is certainly not a case of some developers not liking change. Version 5.1 will be a welcome change. At last we shall be able to produce real Windows style products. But VIP...well I shall not repeat myself. I cannot speak for the development community, but I would suggest that ProIV put all its resources on the kernel. That is after all what our customers see, not the development environment.
I would also suggest not restricting the way we work. One development environment may very well damage some of us out here.
It is encouraging that ProIV want to include many utilities into the core product, and I realise that what is not covered by these utilities, the API will be able to cater with. And I look forward to seeing and using these facilities.
It feels that these comments are all falling on deaf ears. ProIV will go ahead with its plans whether any of us like it or not.
Since you have entered into this dialogue, it does appear that you have NOT been listening. Just read through the posts. Look at the figures. Believe it or not this site brings together more than 300 developers (figures based on the names database). So I would have thought, you would be paying close attention to what people are saying here.
This is certainly not a case of some developers not liking change. Version 5.1 will be a welcome change. At last we shall be able to produce real Windows style products. But VIP...well I shall not repeat myself. I cannot speak for the development community, but I would suggest that ProIV put all its resources on the kernel. That is after all what our customers see, not the development environment.
I would also suggest not restricting the way we work. One development environment may very well damage some of us out here.
It is encouraging that ProIV want to include many utilities into the core product, and I realise that what is not covered by these utilities, the API will be able to cater with. And I look forward to seeing and using these facilities.
It feels that these comments are all falling on deaf ears. ProIV will go ahead with its plans whether any of us like it or not.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
