[dev] [commits] Horde branch master updated. 81be85dcd32bca5ca1cd7d3fe261f4fab549f8b7

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> commit 8209fd9a5dbdb40ba18dcc27e4d26641b8a99ce6
>>> Author: Michael M Slusarz <slusarz at horde.org>
>>> Date:   Wed Feb 26 22:43:12 2014 -0700
>>>
>>>   Barcode generation is cool... but also a potential script that  
>>> can be abused since it doesn't require authentication
>>>
>>>   We also don't link to it anywhere.
>>
>>
>> This is technically a BC break. Just because WE don't link to it  
>> doesn't mean a custom horde application doesn't.
>
> Don't agree with this.
>
> First, this is explicitly marked as a utility.  To me, "utility"  
> means a tool to use with a given distribution/package.

The script may or may not belong in a differently named folder. That's  
besides the point. It should have probably been moved to the services  
directory at some point during the H3 to H4 refactoring.

>  Future distributions may not need that utility since it becomes obsolete.

That's still not an argument to remove it, just for marking it  
obsolete; to be removed in the next BC breaking major version.  
Besides, what made the barcode functionality obsolete?

> Thus, there is no guarantee any scripts in here can exist.  This is  
> really no different than the bin/ directory - with the difference  
> being that this utility was designed to run from the web while the  
> bin directory is CLI.  But bin scripts can (and have)  
> appeared/disappeared as needed.

IMO, this is different then a bin/* file (though even there, I would  
disagree that ANY file in that directory could disappear, or have a BC  
breaking change in arguments in a point release). It's used in an  
application to output an image from an <img> tag. Just like the img/*  
scripts in Ansel. Regardless of if it's documented on a wiki page  
somewhere the point is that other applications could very well be  
using it in <img> tags. Upgrading to Horde 5.2 would break the  
applications. That's unacceptable in a point release. The fact that  
there is nothing in the file header to indicate that it's only an  
"internal" utility could be used as an argument just as easily as the  
fact that there is nothing in some other documentation somewhere to  
indicate that it is available.

> Second, this isn't a part of the API.  Individual scripts have never  
> been guaranteed to remain the same across releases.

If there is a possibility that they can be accessed by a custom Horde  
app, then they absolutely must remain available. Where, exactly, is  
the API documentation that states that these scripts are not  
guaranteed to be available across minor releases? You keep referring  
to the "official API"; Where, exactly, is this official API  
documented? I'm not talking about the API docs on dev.horde.org, I'm  
talking about whatever documentation says that certain files are to be  
accessed in certain ways and not in any other way. I have to say if I,  
a core developer, was writing some custom app that needed this  
functionality, I wouldn't hesitate to use something like Horde::url to  
obtain a link to that file. If a core developer doesn't know that this  
is not the "acceptable" way to access this global Horde functionality,  
then what hope does a general developer have in keeping their custom  
app safe from BC breaks in a major point release?

> The only way to guarantee links is by using Horde_Registry methods.   
> Since this script isn't included there  -- unlike, say, ajax.php or  
> prefs.php or portal.php -- it's not part of the API.  "Framework"  
> doesn't mean a consumer can link willy-nilly to any file included in  
> a particular version - that's what a defined API is for.

No, but they should be able to count on a functionality that has  
existed in some major version to persist in that same major version.  
It's bad enough to remove the WAY you access a functionality within  
the same major version, but you are also completely removing the  
functionality.

> Imagine a JS file in an application.  It's theoretical that someone  
> could link to them directly.  But that doesn't make it part of the  
> API.

Of course not, because it is specific to that application, and if it  
disappears, it's not an issue becuase it's only that application that  
is affected. The difference here is that the Horde application  
provides functionality to be made available to any and all Horde  
applications.

> The exception being scripts accessible via a Horde_Script_Package  
> class, since this make those scripts part of the explicitly defined  
> API.  (Also, scripts in the global Horde scope don't count since  
> they may be linked to by more than one application).

This last point is exactly what I'm saying. This file could be linked  
to by any Horde application. It exists in the Horde application,  
providing a service, or utility functionality, to any other Horde  
application.

-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20140227/a840483f/attachment-0001.bin>