Michael Kaye wrote:
> +1
>
> Has the new API lost all the static methods that meant I had to rewrite
> the old API? And can I second Jose's statement on wiring spring beans up
> and requiring concrete implementations -- It's entirely the Wrong Way to
> do any of it.
>
The code will be much more "interfacy" than what you have seen so far
> If the new code is nearly ready, can we also check that the licence is
> one that's freely contributable to, and freely modifiable, and so avoid
> similar issues to the ones we had trying to release my changes into the
> main source repository last time?
>
The new license will be GPL, which means that, if you decide to
redistribute a modified version, you must make your changes available
under GPL.
As far as contributing to the code goes, all ideas and suggestions will
be welcome, but I want to retain the complete copyright of the complete
code, so I won't need to go and look for anyone's approval in case I
want to provide the code to someone else under a different license.
The new API is a total rewrite of the old API.

Luca

> Michael
>
> Jose Alberto Fernandez wrote:
>
>> Hi Luca,
>>
>> I indeed like elegance, but only if it brings future flexibility :)
>>
>> My main issue with the old WURFL and with the version of the new I saw
>> is the lack of the implementation hidding principle in the API. In the
>> new version, the object types to be injected by spring are define to
>> be concrete classes and not interfaces. What that means is that there
>> is no way to, for example, have different implementations or
>> strategies available.
>>
>> It may be interesting from some sites to, for example, load
>> definitions lazily. You have a server with the full WURFL and you have
>> your actual AppServers loading from it only the definitions they need.
>> You could easily hide such setting if the API were based on interfaces.
>>
>> Now, you ask, why do you need to hide this? Well I use WALL, and I do
>> not want to change WALL to understand different strategies. If WALL
>> where only aware of interfaces, one could replace implementations in
>> Spring and have different strategies available.
>>
>> BTW, this is why I mentioned "Berlin-WALL" on some message, the idea
>> of having a version of WALL that uses the DDR API. Not necessarily
>> written by your team, but with the same idea of simply being a TAG
>> library (as oppose to some larger environment like MyMobileWeb
>> requiring pre-compilation and such).
>>
>> The more alternatives that we can plug and play the better for the
>> ecology.
>>
>> Jose Alberto
>>
>> --- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:
>>
>>> So, I and the WURFL API programmers have been doing some thinking about
>>> making the new Java API more Object-Oriented.
>>> (as an aside, are are implementing SAX, which, according to preliminary
>>> tests, seems to save space and time).
>>>
>>> One of the problems when talking with Java good programmers, is that
>>> elegance and OO quickly becomes a divine property all by itself, weeks
>>> go by and still no actual code is released. But I digress....
>>>
>>> Back to the point if the new API should be more OO, I am a bit
>>> perplexed. On one hand, I understand the point of having something more
>>> OO which is easily pluggable with Spring. On the other hand, I think
>>> that compatibility with the old API should also be maintained to some
>>> extent. After all, I don't remember anyone who had a problem
>>> understanding UAMAnager and CapabilityMatrix, and integrating them with
>>> their application...
>>>
>>> Anyway, what's people's opinion about this matter? should backward
>>> compatibility be preserved? or do you want to deal with a Device object
>>> that encapsulates all knowledge of capabilities?
>>>
>>> Thank you
>>>
>>> Luca
>>>
>>> Jose Alberto Fernandez wrote:
>>>
>>>> Another point here is whether the API should be used based on an
>>>> interface or a fixed concrete implementation. Maybe I am too OO, but
>>>> why does the new API returns Strings for representing the device? Why
>>>> not an object encapsulating the device definition.
>>>>
>>>> interface DeviceDefinition {...}
>>>>
>>>> DeviceDefinition d = WurflSupport.getDeviceFromUALoose(request);
>>>>
>>>> String cX = d.getCapability("X");
>>>>
>>>> String markup = d.getWallMarkup();
>>>>
>>>> String mimeType = d.getMimeType();
>>>>
>>>> You get the idea. The change is minimal in principle, but it would
>>>> allow people to do many things without breaking the API to WALL or
>>>> other component using WURFL.
>>>>
>>>> Using Spring, one could change the implementation of DeviceDefinition
>>>> so as to extend it with additional functionality specific to a project
>>>> or having a lazier implementation that uses a secondary cache.
>>>>
>>>> I guess WurflSupport could also be an interface that can be injected
>>>> using Spring. That way one can have remote Wurfl services, caches,
>>>> Terracotta able implementations, Tera-implementations, you name it.
>>>> And the rest of the code would not even notice.
>>>>
>>>>
>>
>>
>
>
>