Loading ...
Sorry, an error occurred while loading the content.
 

BIG Announcemenet: New WURFL APIs (PHP and Java) officially released

Expand Messages
  • Luca Passani
    People, I know that many of you have enjoyed plenty of sneak previews and quite a lot of sneak deployments of the new APIs. But now it s for real: they are
    Message 1 of 9 , Mar 12 3:28 PM
      People, I know that many of you have enjoyed plenty of sneak previews
      and quite a lot of sneak deployments of the new APIs.

      But now it's for real: they are officially announced and released:

      What is new and why upgrading is a good idea:
      http://wurfl.sourceforge.net/newapi/

      Java API (Spring-Framework based and highly configurable)
      http://wurfl.sourceforge.net/njava/

      PHP API (more modular, controllable, and object oriented)
      http://wurfl.sourceforge.net/nphp/

      In addition, WNG:
      http://wurfl.sourceforge.net/wng/

      and an extra goodie: the old WALL library, retrofitted to work with the
      new API:
      https://sourceforge.net/project/showfiles.php?group_id=55408&package_id=312984
      (it also contains some of the features requested about style and script
      attribute and link).

      Little but important notice: we have now moved to the release system
      provided by SourceForge. Apparently, SF did not like people to offer
      large files for download in the web server (they even had a throttle
      mechanism for download speed to disincentivize that practice).

      Comments are welcome

      Enjoy

      Luca
    • Alex Kerr
      Looks excellent. Big kudos to all involved. If I change the caching provider after 1st installation, will that be ok, and if not what would I do to make it ok?
      Message 2 of 9 , Mar 13 6:57 AM
        Looks excellent. Big kudos to all involved.

        If I change the caching provider after 1st installation, will that be ok, and if not what would I do to make it ok?

        If I use a caching provider other than the disk, does that replace the disk cache or is it in addition and if so then in what circumstances does it get used? (Just thinking of the important note in the php doc: "The disk cache should not be confused with additional in-memory caching mechanisms such as MEMCache which you may also want to adopt for better performance.")

        Is the MySQL cache provider basically offering what TeraWURFL offered? (in terms of performance, aside from the better heuristics that the new WURFL API offers over TeraWURFL).

        Many thanks,
        Alex


        --- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:
        >
        >
        > People, I know that many of you have enjoyed plenty of sneak previews
        > and quite a lot of sneak deployments of the new APIs.
        >
        > But now it's for real: they are officially announced and released:
        >
        > What is new and why upgrading is a good idea:
        > http://wurfl.sourceforge.net/newapi/
        >
        > Java API (Spring-Framework based and highly configurable)
        > http://wurfl.sourceforge.net/njava/
        >
        > PHP API (more modular, controllable, and object oriented)
        > http://wurfl.sourceforge.net/nphp/
        >
        > In addition, WNG:
        > http://wurfl.sourceforge.net/wng/
        >
        > and an extra goodie: the old WALL library, retrofitted to work with the
        > new API:
        > https://sourceforge.net/project/showfiles.php?group_id=55408&package_id=312984
        > (it also contains some of the features requested about style and script
        > attribute and link).
        >
        > Little but important notice: we have now moved to the release system
        > provided by SourceForge. Apparently, SF did not like people to offer
        > large files for download in the web server (they even had a throttle
        > mechanism for download speed to disincentivize that practice).
        >
        > Comments are welcome
        >
        > Enjoy
        >
        > Luca
        >
      • daniel_alonso_heras
        Hello. We have been taking a look at new Wurfl Java API in order to adapt Alembik from the old to the new one, and we have some questions about its usage. Is
        Message 3 of 9 , Mar 24 6:01 AM
          Hello.

          We have been taking a look at new Wurfl Java API in order to adapt Alembik from the old to the new one, and we have some questions about its usage.

          Is it mandatory to use a web.xml file or Spring Framework for configuring Wurfl API? Our problem is that we have to use it outside the web container scope.

          And the other question, is there any way to get inference tables info from Wurfl API? We have been searching for it in the Javadoc with no success, and just viewing in WurflVideo Ice Cold´s mail and responses we think, that now it is a programmer task... Won´t be better to implement it in Wurfl API? Just providing the max supported values for each device, not by verifying if the device screen is big enough in programmer side. We think this should be in Wurfl API.

          What do you think about it?

          Dani
          Alembik Team



          --- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:
          >
          >
          > People, I know that many of you have enjoyed plenty of sneak previews
          > and quite a lot of sneak deployments of the new APIs.
          >
          > But now it's for real: they are officially announced and released:
          >
          > What is new and why upgrading is a good idea:
          > http://wurfl.sourceforge.net/newapi/
          >
          > Java API (Spring-Framework based and highly configurable)
          > http://wurfl.sourceforge.net/njava/
          >
          > PHP API (more modular, controllable, and object oriented)
          > http://wurfl.sourceforge.net/nphp/
          >
          > In addition, WNG:
          > http://wurfl.sourceforge.net/wng/
          >
          > and an extra goodie: the old WALL library, retrofitted to work with the
          > new API:
          > https://sourceforge.net/project/showfiles.php?group_id=55408&package_id=312984
          > (it also contains some of the features requested about style and script
          > attribute and link).
          >
          > Little but important notice: we have now moved to the release system
          > provided by SourceForge. Apparently, SF did not like people to offer
          > large files for download in the web server (they even had a throttle
          > mechanism for download speed to disincentivize that practice).
          >
          > Comments are welcome
          >
          > Enjoy
          >
          > Luca
          >
        • Luca Passani
          Hi Daniel, comments in-line: ... No. It s not mandatory. You can create a simple class that creates all the objects required by the API in the main() method,
          Message 4 of 9 , Mar 24 10:01 AM
            Hi Daniel, comments in-line:

            daniel_alonso_heras wrote:
            > Hello.
            >
            > We have been taking a look at new Wurfl Java API in order to adapt Alembik from the old to the new one, and we have some questions about its usage.
            >
            > Is it mandatory to use a web.xml file or Spring Framework for configuring Wurfl API? Our problem is that we have to use it outside the web container scope.
            >

            No. It's not mandatory. You can create a simple class that creates all
            the objects required by the API in the main() method, connects them
            together and off you go.


            > And the other question, is there any way to get inference tables info from Wurfl API? We have been searching for it in the Javadoc with no success, and just viewing in WurflVideo Ice Cold´s mail and responses we think, that now it is a programmer task... Won´t be better to implement it in Wurfl API? Just providing the max supported values for each device, not by verifying if the device screen is big enough in programmer side. We think this should be in Wurfl API.
            >
            > What do you think about it?
            >

            I am not against the idea, but I would like to solidify the use cases
            for this a little bit before I start adding this kind of virtual methods
            to the API. Can you provide a little spec of how you envision the API
            for this? or should this simply be a static class which returns the
            values in the inference table?

            Luca
          • daniel_alonso_heras
            Hi!! Thanks for response. In order to add some kind of ponderation in level values. In a first step we would check the device screen against the possible
            Message 5 of 9 , Mar 25 5:41 AM
              Hi!!

              Thanks for response.

              In order to add some kind of ponderation in level values. In a first step we would check the device screen against the possible typical picture sizes for that level.... and then return the biggest as possible. This means that the picture size never could be bigger than screen size. The default returned value would be QCIF, except for h263 level 50, that would be CIF.

              Then with this picture size it would be easy to return a max value for video frame rate and max video bit rate.

              In Java code it could be arranged like this.

              The net.sourceforge.wurfl.core.Device's getVideo() method would return an internal Video class with 3 properties:

              public class Video
              {
              private Resolution maxResolution;
              private String maxFrameRate;
              private String maxBitRate; // in kbps.
              }


              where Resolution would be an Enum:

              public static enum Resolution
              {
              SQCIF ("128","96"),
              ...

              private Resolution (String width, String height)
              ...

              public String getWidth() ...
              public String getHeight() ...
              }


              So it could be possible to fill in all the values while obtaining the Device object from the WURFLManager's getDeviceForRequest(...) method.


              In this scenario WURFL API would have to maintain all inference tables.


              public class InferenceTable
              {
              private String codec;
              private Map<String, List<Video>> levels;
              private Video defaultVideo;
              .........

              public Video getVideo (String level, String deviceWidth, String deviceHeight);
              }


              A rough version of getVideo(...) pseudo-algorithm could look like this:

              {
              List<Video> = levels.get(level);

              iterate List<Video>
              {
              if device screen is big enough
              return Video
              }

              return defaultVideo;
              }

              List<Video> would be created in order so first evaluate higger resolutions.


              All inference table would be initialized (from a separate XML file?) and stored in the memory.

              We think that it may be useful to expose them too via WURFLManager's methods:

              public InferenceTable getInferenceTables(String codec);
              public InferenceTable[] getInferenceTables();


              What do you think?
              Any kind of suggestion to improve it?


              Dani
              Alembik Team



              --- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:

              > > ........

              > > And the other question, is there any way to get inference tables info from Wurfl API? We have been searching for it in the Javadoc with no success, and just viewing in WurflVideo Ice Cold´s mail and responses we think, that now it is a programmer task... Won´t be better to implement it in Wurfl API? Just providing the max supported values for each device, not by verifying if the device screen is big enough in programmer side. We think this should be in Wurfl API.
              > >
              > > What do you think about it?
              > >
              >
              > I am not against the idea, but I would like to solidify the use cases
              > for this a little bit before I start adding this kind of virtual methods
              > to the API. Can you provide a little spec of how you envision the API
              > for this? or should this simply be a static class which returns the
              > values in the inference table?
              >
              > Luca
              >
            • Luca Passani
              Thanks for this Daniel. To me, this seems ad-hoc enough that I wouldn t want to write it in stone (i.e. in the API). It would be better to write a tutorial
              Message 6 of 9 , Mar 25 4:04 PM
                Thanks for this Daniel. To me, this seems ad-hoc enough that I wouldn't
                want to write it in stone (i.e. in the API).

                It would be better to write a tutorial which explains how this could be
                an OK method to do things, but not necessarily the only one.
                For example, I know that some companies look at the UAProf of a device
                (does the URL contain either the "2G" or "3G" substring) to understand
                whether a device is using the 3G network and decide to serve a different
                version based on that.

                Others still may be using different tricks/parameters (it also depends
                on what "partition" they have adopted).

                Can't you create a tiny Alembik library on top of the API to implement
                the logic that works for you?

                Luca

                daniel_alonso_heras wrote:
                > Hi!!
                >
                > Thanks for response.
                >
                > In order to add some kind of ponderation in level values. In a first step we would check the device screen against the possible typical picture sizes for that level.... and then return the biggest as possible. This means that the picture size never could be bigger than screen size. The default returned value would be QCIF, except for h263 level 50, that would be CIF.
                >
                > Then with this picture size it would be easy to return a max value for video frame rate and max video bit rate.
                >
                > In Java code it could be arranged like this.
                >
                > The net.sourceforge.wurfl.core.Device's getVideo() method would return an internal Video class with 3 properties:
                >
                > public class Video
                > {
                > private Resolution maxResolution;
                > private String maxFrameRate;
                > private String maxBitRate; // in kbps.
                > }
                >
                >
                > where Resolution would be an Enum:
                >
                > public static enum Resolution
                > {
                > SQCIF ("128","96"),
                > ...
                >
                > private Resolution (String width, String height)
                > ...
                >
                > public String getWidth() ...
                > public String getHeight() ...
                > }
                >
                >
                > So it could be possible to fill in all the values while obtaining the Device object from the WURFLManager's getDeviceForRequest(...) method.
                >
                >
                > In this scenario WURFL API would have to maintain all inference tables.
                >
                >
                > public class InferenceTable
                > {
                > private String codec;
                > private Map<String, List<Video>> levels;
                > private Video defaultVideo;
                > .........
                >
                > public Video getVideo (String level, String deviceWidth, String deviceHeight);
                > }
                >
                >
                > A rough version of getVideo(...) pseudo-algorithm could look like this:
                >
                > {
                > List<Video> = levels.get(level);
                >
                > iterate List<Video>
                > {
                > if device screen is big enough
                > return Video
                > }
                >
                > return defaultVideo;
                > }
                >
                > List<Video> would be created in order so first evaluate higger resolutions.
                >
                >
                > All inference table would be initialized (from a separate XML file?) and stored in the memory.
                >
                > We think that it may be useful to expose them too via WURFLManager's methods:
                >
                > public InferenceTable getInferenceTables(String codec);
                > public InferenceTable[] getInferenceTables();
                >
                >
                > What do you think?
                > Any kind of suggestion to improve it?
                >
                >
                > Dani
                > Alembik Team
                >
                >
                >
                > --- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:
                >
                >
                >>> ........
                >>>
                >
                >
                >>> And the other question, is there any way to get inference tables info from Wurfl API? We have been searching for it in the Javadoc with no success, and just viewing in WurflVideo Ice Cold´s mail and responses we think, that now it is a programmer task... Won´t be better to implement it in Wurfl API? Just providing the max supported values for each device, not by verifying if the device screen is big enough in programmer side. We think this should be in Wurfl API.
                >>>
                >>> What do you think about it?
                >>>
                >>>
                >> I am not against the idea, but I would like to solidify the use cases
                >> for this a little bit before I start adding this kind of virtual methods
                >> to the API. Can you provide a little spec of how you envision the API
                >> for this? or should this simply be a static class which returns the
                >> values in the inference table?
                >>
                >> Luca
                >>
                >>
                >
                >
                >
                >
                > ------------------------------------
                >
                > As of July 14 2005, it's much easier to be banned from WMLProgramming!
                > Please fail to read http://groups.yahoo.com/group/wmlprogramming/ before you post.Yahoo! Groups Links
                >
                >
                >
                >
                >
              • daniel_alonso_heras
                Hello. And what about putting only the inference tables (filled with values) into Wurfl API? Thanks!! Dani Alembik Team.
                Message 7 of 9 , Mar 26 2:58 AM
                  Hello.

                  And what about putting only the inference tables (filled with values) into Wurfl API?

                  Thanks!!

                  Dani
                  Alembik Team.



                  --- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:
                  >
                  >
                  > Thanks for this Daniel. To me, this seems ad-hoc enough that I wouldn't
                  > want to write it in stone (i.e. in the API).
                  >
                  > It would be better to write a tutorial which explains how this could be
                  > an OK method to do things, but not necessarily the only one.
                  > For example, I know that some companies look at the UAProf of a device
                  > (does the URL contain either the "2G" or "3G" substring) to understand
                  > whether a device is using the 3G network and decide to serve a different
                  > version based on that.
                  >
                  > Others still may be using different tricks/parameters (it also depends
                  > on what "partition" they have adopted).
                  >
                  > Can't you create a tiny Alembik library on top of the API to implement
                  > the logic that works for you?
                  >
                  > Luca
                  >
                  > daniel_alonso_heras wrote:
                  > > Hi!!
                  > >
                  > > Thanks for response.
                  > >
                  > > In order to add some kind of ponderation in level values. In a first step we would check the device screen against the possible typical picture sizes for that level.... and then return the biggest as possible. This means that the picture size never could be bigger than screen size. The default returned value would be QCIF, except for h263 level 50, that would be CIF.
                  > >
                  > > Then with this picture size it would be easy to return a max value for video frame rate and max video bit rate.
                  > >
                  > > In Java code it could be arranged like this.
                  > >
                  > > The net.sourceforge.wurfl.core.Device's getVideo() method would return an internal Video class with 3 properties:
                  > >
                  > > public class Video
                  > > {
                  > > private Resolution maxResolution;
                  > > private String maxFrameRate;
                  > > private String maxBitRate; // in kbps.
                  > > }
                  > >
                  > >
                  > > where Resolution would be an Enum:
                  > >
                  > > public static enum Resolution
                  > > {
                  > > SQCIF ("128","96"),
                  > > ...
                  > >
                  > > private Resolution (String width, String height)
                  > > ...
                  > >
                  > > public String getWidth() ...
                  > > public String getHeight() ...
                  > > }
                  > >
                  > >
                  > > So it could be possible to fill in all the values while obtaining the Device object from the WURFLManager's getDeviceForRequest(...) method.
                  > >
                  > >
                  > > In this scenario WURFL API would have to maintain all inference tables.
                  > >
                  > >
                  > > public class InferenceTable
                  > > {
                  > > private String codec;
                  > > private Map<String, List<Video>> levels;
                  > > private Video defaultVideo;
                  > > .........
                  > >
                  > > public Video getVideo (String level, String deviceWidth, String deviceHeight);
                  > > }
                  > >
                  > >
                  > > A rough version of getVideo(...) pseudo-algorithm could look like this:
                  > >
                  > > {
                  > > List<Video> = levels.get(level);
                  > >
                  > > iterate List<Video>
                  > > {
                  > > if device screen is big enough
                  > > return Video
                  > > }
                  > >
                  > > return defaultVideo;
                  > > }
                  > >
                  > > List<Video> would be created in order so first evaluate higger resolutions.
                  > >
                  > >
                  > > All inference table would be initialized (from a separate XML file?) and stored in the memory.
                  > >
                  > > We think that it may be useful to expose them too via WURFLManager's methods:
                  > >
                  > > public InferenceTable getInferenceTables(String codec);
                  > > public InferenceTable[] getInferenceTables();
                  > >
                  > >
                  > > What do you think?
                  > > Any kind of suggestion to improve it?
                  > >
                  > >
                  > > Dani
                  > > Alembik Team
                  > >
                  > >
                  > >
                • Filippo De Luca
                  Hi Daniel, According to the wurfl 1.0 API architecture, is possible to develop a Device implementation, and the factory, returning some kind of values, based
                  Message 8 of 9 , Mar 26 4:03 AM
                    Hi Daniel,
                    According to the wurfl 1.0 API architecture, is possible to develop a Device
                    implementation, and the factory, returning some kind of values, based upon
                    capabilities values.

                    So it is possible making a implementation of Device, maybe a decorator,
                    having a reference to InferenceTable and the method getVideo() suggested by
                    you. But i think it is not good to have this implementation in API, it is
                    bettere to have it as extension, you don't think so?

                    The spring configuration should look like:

                    <!-- DeviceProvider -->
                    <bean id="deviceProvider"
                    class="net.sourceforge.wurfl.core.VideoDeviceProvider">
                    <constructor-arg ref="wurflModel" />
                    <constructor-arg ref="markupResolver" />
                    <constructor-arg ref="capabilitiesHolderFactory" />
                    <constructor-arg ref="inferenceTable" />
                    </bean>


                    2009/3/26 daniel_alonso_heras <daniel.alonso.heras@...>

                    > Hello.
                    >
                    > And what about putting only the inference tables (filled with values) into
                    > Wurfl API?
                    >
                    > Thanks!!
                    >
                    >
                    > Dani
                    > Alembik Team.
                    >
                    > --- In wmlprogramming@yahoogroups.com <wmlprogramming%40yahoogroups.com>,
                    > Luca Passani <passani@...> wrote:
                    > >
                    > >
                    > > Thanks for this Daniel. To me, this seems ad-hoc enough that I wouldn't
                    > > want to write it in stone (i.e. in the API).
                    > >
                    > > It would be better to write a tutorial which explains how this could be
                    > > an OK method to do things, but not necessarily the only one.
                    > > For example, I know that some companies look at the UAProf of a device
                    > > (does the URL contain either the "2G" or "3G" substring) to understand
                    > > whether a device is using the 3G network and decide to serve a different
                    > > version based on that.
                    > >
                    > > Others still may be using different tricks/parameters (it also depends
                    > > on what "partition" they have adopted).
                    > >
                    > > Can't you create a tiny Alembik library on top of the API to implement
                    > > the logic that works for you?
                    > >
                    > > Luca
                    > >
                    > > daniel_alonso_heras wrote:
                    > > > Hi!!
                    > > >
                    > > > Thanks for response.
                    > > >
                    > > > In order to add some kind of ponderation in level values. In a first
                    > step we would check the device screen against the possible typical picture
                    > sizes for that level.... and then return the biggest as possible. This means
                    > that the picture size never could be bigger than screen size. The default
                    > returned value would be QCIF, except for h263 level 50, that would be CIF.
                    > > >
                    > > > Then with this picture size it would be easy to return a max value for
                    > video frame rate and max video bit rate.
                    > > >
                    > > > In Java code it could be arranged like this.
                    > > >
                    > > > The net.sourceforge.wurfl.core.Device's getVideo() method would return
                    > an internal Video class with 3 properties:
                    > > >
                    > > > public class Video
                    > > > {
                    > > > private Resolution maxResolution;
                    > > > private String maxFrameRate;
                    > > > private String maxBitRate; // in kbps.
                    > > > }
                    > > >
                    > > >
                    > > > where Resolution would be an Enum:
                    > > >
                    > > > public static enum Resolution
                    > > > {
                    > > > SQCIF ("128","96"),
                    > > > ...
                    > > >
                    > > > private Resolution (String width, String height)
                    > > > ...
                    > > >
                    > > > public String getWidth() ...
                    > > > public String getHeight() ...
                    > > > }
                    > > >
                    > > >
                    > > > So it could be possible to fill in all the values while obtaining the
                    > Device object from the WURFLManager's getDeviceForRequest(...) method.
                    > > >
                    > > >
                    > > > In this scenario WURFL API would have to maintain all inference tables.
                    > > >
                    > > >
                    > > > public class InferenceTable
                    > > > {
                    > > > private String codec;
                    > > > private Map<String, List<Video>> levels;
                    > > > private Video defaultVideo;
                    > > > .........
                    > > >
                    > > > public Video getVideo (String level, String deviceWidth, String
                    > deviceHeight);
                    > > > }
                    > > >
                    > > >
                    > > > A rough version of getVideo(...) pseudo-algorithm could look like this:
                    > > >
                    > > > {
                    > > > List<Video> = levels.get(level);
                    > > >
                    > > > iterate List<Video>
                    > > > {
                    > > > if device screen is big enough
                    > > > return Video
                    > > > }
                    > > >
                    > > > return defaultVideo;
                    > > > }
                    > > >
                    > > > List<Video> would be created in order so first evaluate higger
                    > resolutions.
                    > > >
                    > > >
                    > > > All inference table would be initialized (from a separate XML file?)
                    > and stored in the memory.
                    > > >
                    > > > We think that it may be useful to expose them too via WURFLManager's
                    > methods:
                    > > >
                    > > > public InferenceTable getInferenceTables(String codec);
                    > > > public InferenceTable[] getInferenceTables();
                    > > >
                    > > >
                    > > > What do you think?
                    > > > Any kind of suggestion to improve it?
                    > > >
                    > > >
                    > > > Dani
                    > > > Alembik Team
                    > > >
                    > > >
                    > > >
                    >
                    >
                    >



                    --
                    Filippo De Luca
                    --------------------------
                    Email: dl.filippo@...
                    Web: http://www.filosganga.it
                    LinkedIn: http://www.linkedin.com/in/filippodeluca
                    mobile: +393395822588


                    [Non-text portions of this message have been removed]
                  • daniel_alonso_heras
                    Hi!! One more question. How can we obtain the values from inference tables? Will there be any static (singleton? enum?) structure provided then? Thank you Dani
                    Message 9 of 9 , Mar 27 3:17 AM
                      Hi!!

                      One more question. How can we obtain the values from inference tables? Will there be any static (singleton? enum?) structure provided then?

                      Thank you

                      Dani
                      Alembik Team


                      --- In wmlprogramming@yahoogroups.com, Filippo De Luca <filosganga80@...> wrote:
                      >
                      > Hi Daniel,
                      > According to the wurfl 1.0 API architecture, is possible to develop a Device
                      > implementation, and the factory, returning some kind of values, based upon
                      > capabilities values.
                      >
                      > So it is possible making a implementation of Device, maybe a decorator,
                      > having a reference to InferenceTable and the method getVideo() suggested by
                      > you. But i think it is not good to have this implementation in API, it is
                      > bettere to have it as extension, you don't think so?
                      >
                      > The spring configuration should look like:
                      >
                      > <!-- DeviceProvider -->
                      > <bean id="deviceProvider"
                      > class="net.sourceforge.wurfl.core.VideoDeviceProvider">
                      > <constructor-arg ref="wurflModel" />
                      > <constructor-arg ref="markupResolver" />
                      > <constructor-arg ref="capabilitiesHolderFactory" />
                      > <constructor-arg ref="inferenceTable" />
                      > </bean>
                      >
                      >
                      > 2009/3/26 daniel_alonso_heras <daniel.alonso.heras@...>
                      >
                      > > Hello.
                      > >
                      > > And what about putting only the inference tables (filled with values) into
                      > > Wurfl API?
                      > >
                      > > Thanks!!
                      > >
                      > >
                      > > Dani
                      > > Alembik Team.
                      > >
                      > > --- In wmlprogramming@yahoogroups.com <wmlprogramming%40yahoogroups.com>,
                      > > Luca Passani <passani@> wrote:
                      > > >
                      > > >
                      > > > Thanks for this Daniel. To me, this seems ad-hoc enough that I wouldn't
                      > > > want to write it in stone (i.e. in the API).
                      > > >
                      > > > It would be better to write a tutorial which explains how this could be
                      > > > an OK method to do things, but not necessarily the only one.
                      > > > For example, I know that some companies look at the UAProf of a device
                      > > > (does the URL contain either the "2G" or "3G" substring) to understand
                      > > > whether a device is using the 3G network and decide to serve a different
                      > > > version based on that.
                      > > >
                      > > > Others still may be using different tricks/parameters (it also depends
                      > > > on what "partition" they have adopted).
                      > > >
                      > > > Can't you create a tiny Alembik library on top of the API to implement
                      > > > the logic that works for you?
                      > > >
                      > > > Luca
                      > > >
                      > > > daniel_alonso_heras wrote:
                      > > > > Hi!!
                      > > > >
                      > > > > Thanks for response.
                      > > > >
                      > > > > In order to add some kind of ponderation in level values. In a first
                      > > step we would check the device screen against the possible typical picture
                      > > sizes for that level.... and then return the biggest as possible. This means
                      > > that the picture size never could be bigger than screen size. The default
                      > > returned value would be QCIF, except for h263 level 50, that would be CIF.
                      > > > >
                      > > > > Then with this picture size it would be easy to return a max value for
                      > > video frame rate and max video bit rate.
                      > > > >
                      > > > > In Java code it could be arranged like this.
                      > > > >
                      > > > > The net.sourceforge.wurfl.core.Device's getVideo() method would return
                      > > an internal Video class with 3 properties:
                      > > > >
                      > > > > public class Video
                      > > > > {
                      > > > > private Resolution maxResolution;
                      > > > > private String maxFrameRate;
                      > > > > private String maxBitRate; // in kbps.
                      > > > > }
                      > > > >
                      > > > >
                      > > > > where Resolution would be an Enum:
                      > > > >
                      > > > > public static enum Resolution
                      > > > > {
                      > > > > SQCIF ("128","96"),
                      > > > > ...
                      > > > >
                      > > > > private Resolution (String width, String height)
                      > > > > ...
                      > > > >
                      > > > > public String getWidth() ...
                      > > > > public String getHeight() ...
                      > > > > }
                      > > > >
                      > > > >
                      > > > > So it could be possible to fill in all the values while obtaining the
                      > > Device object from the WURFLManager's getDeviceForRequest(...) method.
                      > > > >
                      > > > >
                      > > > > In this scenario WURFL API would have to maintain all inference tables.
                      > > > >
                      > > > >
                      > > > > public class InferenceTable
                      > > > > {
                      > > > > private String codec;
                      > > > > private Map<String, List<Video>> levels;
                      > > > > private Video defaultVideo;
                      > > > > .........
                      > > > >
                      > > > > public Video getVideo (String level, String deviceWidth, String
                      > > deviceHeight);
                      > > > > }
                      > > > >
                      > > > >
                      > > > > A rough version of getVideo(...) pseudo-algorithm could look like this:
                      > > > >
                      > > > > {
                      > > > > List<Video> = levels.get(level);
                      > > > >
                      > > > > iterate List<Video>
                      > > > > {
                      > > > > if device screen is big enough
                      > > > > return Video
                      > > > > }
                      > > > >
                      > > > > return defaultVideo;
                      > > > > }
                      > > > >
                      > > > > List<Video> would be created in order so first evaluate higger
                      > > resolutions.
                      > > > >
                      > > > >
                      > > > > All inference table would be initialized (from a separate XML file?)
                      > > and stored in the memory.
                      > > > >
                      > > > > We think that it may be useful to expose them too via WURFLManager's
                      > > methods:
                      > > > >
                      > > > > public InferenceTable getInferenceTables(String codec);
                      > > > > public InferenceTable[] getInferenceTables();
                      > > > >
                      > > > >
                      > > > > What do you think?
                      > > > > Any kind of suggestion to improve it?
                      > > > >
                      > > > >
                      > > > > Dani
                      > > > > Alembik Team
                      > > > >
                      > > > >
                      > > > >
                      > >
                      > >
                      > >
                      >
                      >
                      >
                      > --
                      > Filippo De Luca
                      > --------------------------
                      > Email: dl.filippo@...
                      > Web: http://www.filosganga.it
                      > LinkedIn: http://www.linkedin.com/in/filippodeluca
                      > mobile: +393395822588
                      >
                      >
                      > [Non-text portions of this message have been removed]
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.