Posted 18 February 2003 - 08:48 AM
I'm trying to create some new security functionality to provide rules such as password minimum lenght, pasword invalid chars, pasword expiry etc.
I think that the files that I need access to are logonf and security, but I only seem to have the filedef for security.
If I'm to write a screen to ask users to enter a new pasword I'm guessing that I'll need to update logonf somehow. Anyone have any ideas or suggestions as to how I could do this or how I could get my hands on the logonf filedef
Posted 21 February 2003 - 01:47 PM
PROIV reserve the right to change any internal file definition without consent, which may result in the failure of any application reliant on the definition.
Any customers requiring access to internal definitions should do so through their account managers or product suppliers.
This helps PROIV keep a track published material and the possible impact/notification of any future changes.
Posted 21 February 2003 - 02:01 PM
I've mentioned this before, but PRO-IV's standard NDA (the last 2 that I've seen at least) contains a double negative at a critical point - in effect it INSISTS that parties to the NDA must give away the information included in the bootstraps (it says you must not not do so). Which is nice... certainly makes the NDA easier to sign!
I still say PRO-IV should just publish the bootstrap file defs with each version anyway - everyone who develops uses them, you wouldn't need to 'track published material and the possible impact ... of future changes' - just publish the changes when you make them and us poor developers will have to cope.
But seriously, make sure that your NDA's are up to scratch because they're not really watertight!
Posted 21 February 2003 - 04:53 PM
Most people have them/know them now anyway.
It helps coders to know them.
It would have helped me save hours and hours of work if I had been given the VIP bootstraps so that we could do work automatically... but since ProIV will not give out VIP bootstraps I had to do things manually.
This is a stupid argument that has been goning on for years and ProIV should publish them.
If they change the bootstraps, then its up to the coder to make the relavent changes to cope with the new definitions.
Posted 21 February 2003 - 10:11 PM
Do you lot REALLY believe that those of us in the real world will continue to stand for that???? Your dying sales numbers tell me that they won't...when will YOU lot get that message?? I know that we may be moving off of ProIV entirely, which puts me outta a job AGAIN....
NO CLOSED SYSTEM EVER FLOURISHED WHEN IN COMPETITION WITH AN OPEN ONE!! Learn from history or be condemmed to repeat it!
I shall now step down off the soapbox..
Thank you for your kind attention.
Posted 21 February 2003 - 10:28 PM
refused the native boots, it's just a courtesy to PROIV.
I will be changing the NDA text (which in my version reads
OK) to encompass the support implications of sites with VIP straps and processes derived from their release.
I wouldn't mind some ideas on this regarding tracking and protection when direct access is made to source. I don't realy wish to police every file and would prefer to be completely open but this could lead to support issues outside our control or responsibility...
Posted 22 February 2003 - 12:07 AM
Are the defs for objprop.pro available yet? We didn't get them with the 5.0 boots when we asked for them...
I confess that I still don't really understand your issue wrt 'tracking and protection'. If you just released all the bootstraps (anything with genuine code in) along with some documentation and a big warning saying 'DON'T CHANGE THESE' then -
1. Changing the data in these files by code or manually outside of PRO-IV's dev tools can't affect the kernel - it just changes software. If I write some code using another tool and it doesn't GEN, that's my problem. If it fails because of something not working as advertised in the kernel, then that's PRO-IV's problem. If I change the bootstraps to suit myself, then I'm an idiot, which is my problem. I've never heard anyone even suggest changing the bootstraps - we all know it would be ridiculous to do it (don't we?). So that shouldn't be a support issue.
2. Tracking's MUCH easier if EVERYONE has the same information - i.e. all of it. Make the bootstraps part of each dev release.
3. Protection? Are you worried about the IP in there or something? I don't think you'd even need an NDA - just make it all part of the dev licence and then we can't transfer to third parties anyway or we break the terms of the original licence.
The bootstraps are an integral part of the language - it's much less functional without them - can't generate code automatically - which is a powerful feature in any language.
Neil, if you can clarify your issues/worries over support, and protection, and tracking, then maybe the developer community can be of some help. After all, many of us work for, or have worked for, software organisations, and have had to deal with similar issues - perhaps we can help PRO-IV to help us?
Posted 22 February 2003 - 06:52 AM
Unless your 'routines' will allow absolutly total access to every field that is needed for a function, then that will not be good enough.
And if it does allow all fields, then why not just give us the file defs!!!
Also... will the 'routines' be written at 'kernel level' or will they just be global functions, that will be slow and unable to cope with large systems with 1000's of functions and the posibility of bugs?
Please, just publish the vip/native bootstraps to everyone (without having to sign something). This will only 'promote' the language... not hurt it!!!
I'm sure that I am not the only one with this view.
I cant think of any language that tries to shield their users from the real source code.... after all.. we are the developers, if we break our applications, then its our fault and we will fix it.
Posted 23 February 2003 - 10:52 PM
When you see the VIPstraps you will realise that they are not much different from the native boots.
Two reasons for this:-
We may in the future choose to gen directly from VIP and
not native or a combination of both and width to retain current compatibility.
The native definitions and data model are old and very unorganised in terms of normalisation, naming and redundancy removal. The current versions of VIP have inherited this poor model and patched functionality via the use of XREF physical files and memory files.
I would really like to move the source to a more modern, performant and resilient architecture in the future which would absolve me from the limitations of PRO-ISAM. I would also like to consider for example moving all object references to 32 character (function,file etc). Which would involve major changes to both source and kernel but why shoe horn that into the current shape.
I understand your personal requirement for full disclosure but you would also be the first to whinge if we make significant changes that affect your use. It is also my experience that the first port of call we developers screw up their source code tends to be PROIV support or this forum - not all developers are as competent with the bootstraps as you and I (and Dan, Chris Pepper Dick Basett etc.....)
Anyway I estimate about 2-3 months before I publish VIPStaps maybe sooner If you guys stop hassling me.
Posted 23 February 2003 - 11:47 PM
I can see no need for changing the layout of the bootstrap files in the way you have, it will just create more places for errors to occur.
I have written (and will hopefully soon finish) a full ProIV function editor that runs of the original bootstaps. I have had no problem making it fast and smooth to edit a function using the existing structure... If I had to update all the files/xref files like VIP has to, then it would be much slower.
The only layout that has caused me some problems with performance is the 'new' objprop.pro since there are so many records in that file. One record for each property is not good.
The only other format that might be more 'standard' would be to store the bootstraps into a flat text ascii file, like most other lanuages.
Posted 24 February 2003 - 08:34 AM
Because your editor or tools need a stationary architecture we have to limit the extent of change !!!
In your abstracted Visual Basic based editor how do you store the source (and I don't mean lines of logic). I would think is held as an object model with reference pointers.
How fast is it when you have to read the pro-isam source
records flatten out the data and send it in chunks client side and then repeat the process to build the function.
Where is the internalexternal linkage information for functions and internal object references etc you work that out on the fly? or walk the entire pro-isam source.
If you want an open developer community why then did you not either contribute to the design and trial of VIP or
create your editor as open source/design. Self-interest pervades!
Posted 24 February 2003 - 11:28 AM
I'd love to see an Open Source project to build a genuinely good PRO-IV editor. I know there are lots of developers out there who've written their own (of varying quality) and I'm sure we could collectively build some seriously good tools. Neil, would PRO-IV be in favour of such a thing? It would need some (but not a lot) active support (particularly in the form of bootstraps) from you guys to make it work really well.
I'd love to see PRO-IV compile source from a sensibly structured set of bootstraps. But I don't expect this is likely to happen, because re-building the kernel from the ground up for all the supported platforms, with the resources that PRO-IV have historically seemed to have for development, doesn't seem probable. My own opinion, for various reasons, is that historically PRO-IV's in-house-developed editors have not been all that good - this may be for all kinds of reasons, which I'm not really interested in anyway.
If we're serious about development tools, maybe this development community should set about creating some, hopefully (though not necessarily) with PRO-IV's blessing. I'd certainly be willing to contribute the editor that I've written over the last 10 years (and that I'm sure I'll never make any money out of directly).
I'll put up a poll to gauge some reaction. Rob, you might want to give some thought to this as well?
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users