Recently KB P122940 "How to implement a RUN-TIME Security within the ABL" was published, but the provided code used seriously outdated techniques, deprecated language elements, and didn't follow development philosophies Progress has been espousing for years.
I sent a note in to that effect, and got a response that it would be updated. The updated code changed things a bit, but the resulting code still didn't follow the Progress line and was functionally broken, so I sent another note in to that effect.
Apparently, rather than spending the one or two hours required to make it Progress-philosophy compliant, someone decided adding the following note was good enough:
"This example above is provided 'as is' for documentation and informative purpose only, it is not following Even Driven programming principles, it is based on Procedural Programming principles, and it is not separating User Interface from Business Logic."
Ordinarily I have nothing but good things to say about PSC TS - but in this instance, if PSC doesn't follow it's own development philosophy in it's KB technical examples and deems a note like this to suffice as a replacement for good development practice, what kind of example does that set for the rest of the Progress development community?
Check http://tinyurl.com/39xs9j to see the KB.
The tinyurl didn't work for me. But that's hardly surprising I did look it up the hard way though.
On the one hand there is a limit to how far they can reasonably be expected to go in a kbase entry. It almost seems like you're asking them to implement something like AutoEdge to illustrate the point and that would, IMHO, be going to far.
On the other hand the disclaimer is pretty lame.
On the third hand... the code that is actually there doesn't seem particularly helpful in illustrating the concept in question.
I think that it is possible to put together some fairly concise event driven code that can be used as a framework for these things and that it would be good to do so. Perhaps we should undertake such a project as a "community service"?
The tinyurl didn't work for me. But that's hardly surprising I did look it up the hard way though.
On the one hand there is a limit to how far they can reasonably be expected to go in a kbase entry. It almost seems like you're asking them to implement something like AutoEdge to illustrate the point and that would, IMHO, be going to far.
I'm thinking that a company that preaches about separating the BL from the UI, being event-driven, etc. - would show that in their sample code, KB entries, etc. to show they actually believe and practice what they've been preaching.
On the other hand the disclaimer is pretty lame.
It appeared after I sent in feedback twice about those very issues.
On the third hand... the code that is actually there doesn't seem particularly helpful in illustrating the concept in question.
It's only useful for checking access to a given program, and even then it falls down because it doesn't return a logical flag to indicate whether the user's allowed in or not.
I think that it is possible to put together some fairly concise event driven code that can be used as a framework for these things and that it would be good to do so.
I could've re-written that code in less than 2 hrs, and been done with it. I'm presuming that a shop the size of Progress with all kinds of internal ABL developers should be able to do the same.
Perhaps we should undertake such a project as a "community service"?
The question then becomes "why"? Progress says "this is the way to go", but when it comes to actually doing it - resorts to a lame disclaimer to get around not doing it. Why should the "community" have to pick up the slack for something Progress should be doing as a matter of course?
I'm thinking that a company that preaches about
separating the BL from the UI, being event-driven,
etc. - would show that in their sample code, KB
entries, etc. to show they actually believe and
practice what they've been preaching.
I mostly agree. At least with the general concept. But a balance needs to be struck between a practical illustration of a particular point and being lost in the forest. When sample code of a point that really only takes a few lines of code to implement requires dozens of pages of framework to be implemented it becomes less than helpful.
In this case it seems to me that the wrong balance has been struck.
I think that it is possible to put together some
fairly concise event driven code that can be used as
a framework for these things and that it would be
good to do so.
I could've re-written that code in less than 2 hrs,
and been done with it.
That sounds like a plan
I'm presuming that a shop the
size of Progress with all kinds of internal ABL
developers...
What fantasy land are you living in?!? It should be painfully obvious that Progress has precious few "ABL" developers in-house.
... should be able to do the same.
If, in fact, they had all kinds of internal "ABL" developers that would make sense.
Perhaps we should undertake such a project as a
"community service"?
The question then becomes "why"?
Progress says "this is the way to go", but when it comes to actually
doing it - resorts to a lame disclaimer to get around
not doing it. Why should the "community" have to pick
up the slack for something Progress should be doing
as a matter of course?
The fame and glory of having your code plastered throughout the kbase?
I'm thinking that a company that preaches about
separating the BL from the UI, being event-driven,
etc. - would show that in their sample code, KB
entries, etc. to show they actually believe and
practice what they've been preaching.
I mostly agree. At least with the general concept.
But a balance needs to be struck between a practical
illustration of a particular point and being lost in
the forest.
Certainly - but this wasn't one of those cases.
In this case it seems to me that the wrong balance
has been struck.
Yep.
I think that it is possible to put together some
fairly concise event driven code that can be used
as
a framework for these things and that it would be
good to do so.
I could've re-written that code in less than 2
>hrs, and been done with it.
That sounds like a plan
So, who'se going to pick up the bill for it? You?
I'm presuming that a shop the
size of Progress with all kinds of internal ABL
developers...
What fantasy land are you living in?!? It
should be painfully obvious that Progress has
precious few "ABL" developers in-house.
Oi! Thats a rather ... odd factoid to find out.
... should be able to do the same.
If, in fact, they had all kinds of internal "ABL"
developers that would make sense.
How many do they have?
>> Perhaps we should undertake such a project as a
>> "community service"?
>>
>> The question then becomes "why"?
>> Progress says "this is the way to go", but when it
>> comes to actually doing it - resorts to a lame
>> disclaimer to get around not doing it. Why should
>> the "community" have to pick up the slack for
>> something Progress should be doing as a matter
>> of course?
The fame and glory of having your code plastered
throughout the kbase?
Lol.....
I've got better things to do with my time.
> What fantasy land are you living in?!? It > should
be painfully obvious that Progress has > precious few "ABL"
developers in-house. Oi! Thats a rather ... odd factoid to find
out. Well, one might qualify this by saying that there probably
are a fair number who work for PSC, but a whole lot of those work
for the consulting arm and many of the remainder work for other
groups who are not tasked on things like writing kbase entries.
I met one once. So I know that the number is (or was) greater than zero.
I'm not going to hold my breath waiting for an authoritative answer but my personal estimate is that the total is approximately 4. And they're pretty busy maintaining the production systems that they support.
There were more than 4 involved in AutoEdge.
That's not the same as writing real code that is being used by real customers to run a real business.
And I'm not sure that I would want it bandied about that it took more than 4 to write AutoEdge
That's not the same as writing real code that is
being used by real customers to run a real business.
And I'm not sure that I would want it bandied about
that it took more than 4 to write AutoEdge
As I commented on another thread (http://www.psdn.com/library/thread.jspa?threadID=3721&tstart=0) I'm not sure where this notion of 4 Architects comes from. We've never publicly stated how many architects were involved, but I can tell you as one of the people involved in the project, there was only 1 lead architect at any point in time on the project, with some development resource, which were few in number, not a huge army of people!!
So no, it didn't take more than 4 architects to write AutoEdge, just 350 doc writers, managers, publicists, hair stylists, personal trainers and a talking moose to make it happen
I'm sure that we all have our own ideas of which parts were contributed by the talking moose ...
I'm assuming we mean this thread: http://progress.atgnow.com/esprogress/jsp/AnswerControls.jsp?directSolutionLink=1&tabs=true&docPropValue=p122940
Yes - it does appear out date - like where is the client-principal?? Something "quick and dirty" to get started would have been better. Something that covers more a "dummies" guide.
1. Create a new DB
2. Add users
3. Set database properties (must allow blank user-ids)
4. Create security administrators (these people also have global SQL-92 access)
5. Create an authentication system
6. Create an authentication domain
Start with following (very bad) _login.p
def input param v as logical no-undo.
DEFINE VARIABLE m_hPrincipal AS HANDLE NO-UNDO.
CREATE CLIENT-PRINCIPAL m_hPrincipal.
SECURITY-POLICY:LOAD-DOMAINS(1). /load the database's securitu domain/
cSessionID% = substring(BASE64-ENCODE(GENERATE-UUID), 1 ,22).
/* Set the user-id */
m_hPrincipal:USER-ID = "test1". /replace with a call to /usr/ucb/whoami on unix or WHOAMI on windows - maybe?/
m_hPrincipal:LOGIN-HOST = "hostname?".
m_hPrincipal:DOMAIN-NAME = "mydomain".
m_hPrincipal:DOMAIN-TYPE = "mtype".
m_hPrincipal:DOMAIN-DESCRIPTION = OPSYS + " operating system process user-id".
m_hPrincipal:SESSION-ID = cSessionID%.
m_hPrincipal:ROLES = "myRole".
m_hPrincipal:SET-PROPERTY("MyProp1","P1").
m_hPrincipal:SET-PROPERTY("MyProp2","P2").
m_hPrincipal:AUDIT-EVENT-CONTEXT = m_hPrincipal:USER-ID + "." + "hostname?".
m_hPrincipal:CLIENT-TTY = SESSION:CLIENT-TYPE + "." + SESSION:DISPLAY-TYPE.
m_hPrincipal:SEAL("accesscode"). /accesscode == accesscode/domainkey in authenticated domain/
SECURITY-POLICY:SET-CLIENT(m_hPrincipal). /log the client in as "test1"/
return.
Then something on the SQL side. This would give the whole thing a nice "round" feel.
I'm assuming we mean this thread:
...
Yes - it does appear out date - like where is the
client-principal?? Something "quick and dirty" to
get started would have been better. Something that
covers more a "dummies" guide.
Actually no - this KB was about doing checks to see if a user was authorized to run a particular program, it had nothing to do with client-principle.
"architects to write" has a scary feel to it -- I'm glad it didn't go that way
Ok, so there was a single architect at any given moment. Apparently there were multiple architects over the life of the project (which explains a few things ) So how many "programmers" were involved? And for how long? What would the FTE equivalent be?