
Pro-iv Bootstraps file defs
Started by
Guest_Mick Rogerson_*
, Feb 13 2001 06:05 PM
25 replies to this topic
#17
Posted 16 February 2001 - 09:57 AM
No one person can talk for the ProIV community. But if you read many of these posts, many I's mean we.
As for the availability of the bootstrap files, this is very interesting news and I hope everyone will have access to up to date bootstrap files as a free download from the ProIV website. Then you can keep track of the downloads.
The news of Version 5 is most interesting and I am sure that many of us will have many comments. I cannot help feel that every new development tool has not taken off in the manner ProIV intended. We have had @MODX, Screen painter, Super Layer, Developer Studio, Forms Designer and
Jade. Only @MODX has been really popular (apologies to SL and DS users). Why should this be any different?
I hope that ProIV listen very carefully to comments that we may have, pay attention to detail (no bug ridden releases that currupt functions) and don't stop us creating own development environments.
I am very encouraged however by you discussing these issues here with us. I hope this becomes a regular event.
As for the availability of the bootstrap files, this is very interesting news and I hope everyone will have access to up to date bootstrap files as a free download from the ProIV website. Then you can keep track of the downloads.
The news of Version 5 is most interesting and I am sure that many of us will have many comments. I cannot help feel that every new development tool has not taken off in the manner ProIV intended. We have had @MODX, Screen painter, Super Layer, Developer Studio, Forms Designer and
Jade. Only @MODX has been really popular (apologies to SL and DS users). Why should this be any different?
I hope that ProIV listen very carefully to comments that we may have, pay attention to detail (no bug ridden releases that currupt functions) and don't stop us creating own development environments.
I am very encouraged however by you discussing these issues here with us. I hope this becomes a regular event.
#20
Posted 16 February 2001 - 12:41 PM
That sounds like a good idea.
I think making the bootstrap files not PRO-ISAM would be a bad way to go, as so many people have apps/utils that they are used to or have written.
Rob D
I think making the bootstrap files not PRO-ISAM would be a bad way to go, as so many people have apps/utils that they are used to or have written.
Rob D
#22
Posted 24 February 2001 - 07:48 AM
So again you're adding another layer in between the code we write and the code that actually gets executed - more opportunity for bugs to rear their ugly heads.
How the source is stored is extremely important I would have thought, so we can generate proper functions.
I don't really believe that the bootstraps will change totally - how can you expect clients with 10000 functions to be totally successful in porting apps to the new framework when previous tools (conversion to SL from Native, and the totally unnecessary 'tool' to convert to 4.0) didn't work reliably, and even occasionally introduced their own bugs into the code?
Perhaps you could explain a bit more about the model you're proposing (architecture-wise at least) so we can see what it's likely to mean for all of our tools?
Cheers
Dan Shannon
How the source is stored is extremely important I would have thought, so we can generate proper functions.
I don't really believe that the bootstraps will change totally - how can you expect clients with 10000 functions to be totally successful in porting apps to the new framework when previous tools (conversion to SL from Native, and the totally unnecessary 'tool' to convert to 4.0) didn't work reliably, and even occasionally introduced their own bugs into the code?
Perhaps you could explain a bit more about the model you're proposing (architecture-wise at least) so we can see what it's likely to mean for all of our tools?
Cheers
Dan Shannon
#23
Posted 24 February 2001 - 09:30 AM
We use the bootstraps for lots of things, I dont think we will not move to version 5 if we cannot access the bootstraps.
I have written a suite of functions that we use for tracking functions that are run and how long they run for, for spotting performance problems with our system.
Our security system relies on the bootstraps.
Our Version control system relies on the bootstraps.
Lots of our utilities relies on the bootstraps.
VIP is going to be a very large and flexable application if its going to support all of that and it will have to if you are not going to give the bootstrap files away.
But, then again... we can work them out ourselves
Rob D
I have written a suite of functions that we use for tracking functions that are run and how long they run for, for spotting performance problems with our system.
Our security system relies on the bootstraps.
Our Version control system relies on the bootstraps.
Lots of our utilities relies on the bootstraps.
VIP is going to be a very large and flexable application if its going to support all of that and it will have to if you are not going to give the bootstrap files away.
But, then again... we can work them out ourselves

Rob D
#24
Guest_Neil Mellis_*
Posted 25 February 2001 - 06:21 PM
Hi
Nice dismisive opening statement!
I want to envolve you guy's and developers that do not contibute to this site in the evolution of VIP. It is important that we get it right. My understanding of the release plan is that 5.0 will be released with @MOD, @MODX, SL (No 5.0 Feature extensions for these) Developer Studio will provide support for 5.0 features VIP will be supplied as an option to migrate code to (This will be a one way process), In Theory even Aide will probably work with some tweaks. Future releases will aim to get everyone into the VIP world.
Developer Studio and VIP have/will have published hooks that can easily invoke version control/release management tools. The runtime bootraps will remain as is and so will still be accesible to you.
One small problem with reverse engineering the new def's in that some no longer take the form of large flat attribute list but object based (and keyed) typed data which requires understanding of the data relationships as well as the layout. Why do it if the API can do it for you. Generally
the abstracted def have just been re keyed by object ref (tag) with the addition of function structure and object property files a tighter and more performant model has been produced.
Nice dismisive opening statement!
I want to envolve you guy's and developers that do not contibute to this site in the evolution of VIP. It is important that we get it right. My understanding of the release plan is that 5.0 will be released with @MOD, @MODX, SL (No 5.0 Feature extensions for these) Developer Studio will provide support for 5.0 features VIP will be supplied as an option to migrate code to (This will be a one way process), In Theory even Aide will probably work with some tweaks. Future releases will aim to get everyone into the VIP world.
Developer Studio and VIP have/will have published hooks that can easily invoke version control/release management tools. The runtime bootraps will remain as is and so will still be accesible to you.
One small problem with reverse engineering the new def's in that some no longer take the form of large flat attribute list but object based (and keyed) typed data which requires understanding of the data relationships as well as the layout. Why do it if the API can do it for you. Generally
the abstracted def have just been re keyed by object ref (tag) with the addition of function structure and object property files a tighter and more performant model has been produced.
#25
Posted 25 February 2001 - 06:34 PM
Why do it if the API can do it for you?
Because we can. And in the true guru/hacker mentality, those of us who've been doing it for long enough will want to find better ways to do it than what we're spoon-fed.
Let's face it, you'll still be storing the code somewhere, most likely in PRO-ISAM files. So why shouldn't we have access directly? If we can provide better tools for ourselves, or for the PRO-IV community, then what has PRO-IV Ltd got to lose?
BTW I'd really like an answer to that question - what have you got to lose if you open up to us? We have a definite interest in all of this - you pay my rent (no Pet Shop Boys references please).
Yours in hope,
Dan Shannon
Because we can. And in the true guru/hacker mentality, those of us who've been doing it for long enough will want to find better ways to do it than what we're spoon-fed.
Let's face it, you'll still be storing the code somewhere, most likely in PRO-ISAM files. So why shouldn't we have access directly? If we can provide better tools for ourselves, or for the PRO-IV community, then what has PRO-IV Ltd got to lose?
BTW I'd really like an answer to that question - what have you got to lose if you open up to us? We have a definite interest in all of this - you pay my rent (no Pet Shop Boys references please).
Yours in hope,
Dan Shannon
#26
Posted 26 February 2001 - 02:40 AM
The API would be a good idea as long as there is FULL control and we are not restricted.
We also need the bootstrap files because I'm sure that the company I work for will not spend large amounts of time just converting our existing utils etc to use the API.
We have better things to do, like pleasing OUR customer!
Rob D
We also need the bootstrap files because I'm sure that the company I work for will not spend large amounts of time just converting our existing utils etc to use the API.
We have better things to do, like pleasing OUR customer!
Rob D
Reply to this topic

0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users