[OpenLayers-Dev] library size & advanced geometry functions

[Eric Lemoine]

On Thu, Feb 5, 2009 at 8:22 PM, Christopher Schmidt
<crschmidt at metacarta.com> wrote:
> On Thu, Feb 05, 2009 at 12:03:35PM -0700, Tim Schaub wrote:
>> Hey-
>>
>> So, users can currently control the size of their library build with a
>> custom build profile.  This works well when there are entire classes
>> that are not needed in an application.
>>
>> In the case of geometries, there is a good bit of functionality that
>> could be added.  I originally considered a separate library that would
>> extend OpenLayers geometries with more advanced functionality.  This
>> would keep the OpenLayers builds small and give more functionality just
>> to those who wanted it.
>>
>> I also know that a whole lot more people would get the opportunity to
>> use the functionality if it were part of OpenLayers.  I like the
>> convention of keeping all extensions to our constructor prototypes in a
>> single file.  However, it is not strictly necessary.  On option for
>> adding functionality that could be excluded from a custom build would be
>> to have additional files that extended the geometry prototypes.
>>
>> What do others think?
>
> I don't have any problem with this, but I do sort of wonder if there
> isn't an amount of diminishing return with regard to smaller OpenLayers.js
> files -- for most users, our library is no bigger than a handful of
> tiles anyway, so users would get a lot more benefit out of just
> configuring their application to have 'buffer: 0' on WMS layers than
> they would from further work on making our core library smaller...

Still, people may complain if the size of the library is high and if
they cannot strip off the things they don't need.

>
> One nice thing about the existing setup is that building a custom
> profile is pretty easy: look for any place in your code that says 'new',
> take the classname after it, and include the file that contains that
> class in your build profile. Everything else should be handled for you
> (with a few exceptions, like renderers).
>
>> 1) Keep piling code into the same geometry files.
>
> I don't see a major problem with this.
>
>> 2) Stop piling code into the geometry files, and go with the separate
>> library idea.
>
> I like this one more than 3).
>
>> 3) Put the stuff in separate files (GeometryEx/ or something).
>
> I wouldn't be against this if others prefer it.

I'd prefer Option 3. Compared to Option 2 it gives better visibility
to the new fonctionality, and makes it easier to users to access that
functionality, it's also simpler to handle in terms of docs, tests,
etc. And compared to Option 1 it provides a way to exclude the
functionality from the single file build, which, as I mentioned above,
I think is what people will expect.

--
Eric