You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2014/07/18 09:49:16 UTC

URLResource reading from svn.apache.org by default?

Hi,

Just saw this in URLResource [1]:

    //TODO: put on CDN of some kind
    DEFAULT_PATH =
"http://svn.apache.org/repos/asf/incubator/devicemap/trunk/data/device-data/src/main/resources/devicedata";

Does this mean users will by default hit svn.apache.org to get the device data?

If yes that's not good, svn.apache.org is not meant to be hit directly
by users of our software.

The risk is ASF infrastructure folks blocking access to that if they
see abnormal loads (and hating us accordingly ;-)

-Bertrand

[1] https://svn.apache.org/repos/asf/incubator/devicemap/trunk/devicemap/java/classifier/src/main/java/org/apache/devicemap/loader/resource/URLResource.java

Re: URLResource reading from svn.apache.org by default?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,

On Fri, Jul 18, 2014 at 4:07 PM, Reza <re...@yahoo.com.invalid> wrote:
> ...2) The download has to be fast. Don't want initialization taking more than
> 1 to 2 seconds. Putting a CDN infront of the URL will solve this....

Ok, download speed is hard to guarantee with public Maven repositories.

-Bertrand

Re: URLResource reading from svn.apache.org by default?

Posted by Reza <re...@yahoo.com.INVALID>.
Well, in the case of the URL loader, the URL and its major version is just a string, ex:

http://cdn.devicemap.apache.org/devicedata/v1/...

Then its just a matter of updating the string with the data version number it supports. Right now its in the client code. Im thinking the default location should be managed by us, the project.

Just incase... the reason for major versioning is to prevent a client from downloading device data in a format it cannot support, thus breaking the client. This is required since loading the data without a URL location reverts to a default location. Im thinking this may be a popular use case. See first example below.


If a client wants to pin itself to a specific version, it can just pass the optional second param to the initDeviceData() method which is the URL to a specific release. See second example below.

Ex:

http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier/src/test/java/org/apache/devicemap/DeviceMapClientUrlTestOptional.java?view=markup


The first test loads from the default location: client.initDeviceData(LoaderOption.URL);

The second test loads from a custom location: client.initDeviceData(LoaderOption.URL, "http://www.rezsoft.org/dmap-data/");

I think its better to have the user defined location be explicit in the code than have to read it from a config file. Would have to think about the tradeoffs more...


________________________________
 From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com> 
Sent: Friday, July 18, 2014 10:14 AM
Subject: Re: URLResource reading from svn.apache.org by default?
 




1) The url has to contain the major version number (ex: ../v1/.., ../v2/.., ../v3/..). This allows for different client versions to work against their supported data. Not sure if maven supports this OOTB or if we just release our own major version LATEST.


Without changing the POM if you wanted Maven to switch between /v1, /v2 or /v3 that would require either user specific properties overriding the project specific one or one could call different profiles. 



On Fri, Jul 18, 2014 at 4:07 PM, Reza <re...@yahoo.com.invalid> wrote:

Is that URL HTTP?
>
>Currently there are 2 requirements for downloading devicemap resources over the internet:
>
>1) The url has to contain the major version number (ex: ../v1/.., ../v2/.., ../v3/..). This allows for different client versions to work against their supported data. Not sure if maven supports this OOTB or if we just release our own major version LATEST.
>
>2) The download has to be fast. Don't want initialization taking more than 1 to 2 seconds. Putting a CDN infront of the URL will solve this.
>
>Am I missing anything else...?
>
>
>
>________________________________
> From: Bertrand Delacretaz <bd...@apache.org>
>To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
>Sent: Friday, July 18, 2014 9:38 AM
>
>Subject: Re: URLResource reading from svn.apache.org by default?
>
>
>
>Hi,
>
>On Fri, Jul 18, 2014 at 3:06 PM, Reza <re...@yahoo.com.invalid> wrote:
>> ...a common complaint about using device classification is that you have to
>> constantly track and maintain new devices...
>
>You might also use the Maven distribution mechanism for these data
>files - in another project I'm using pax URL to resolve URLs like
>
>mvn:org.apache.sling/org.apache.sling.commons.log/LATEST
>
>to get the corresponding artifact from a Maven repository.
>
>The nice thing with that is that you don't have to worry about infrastructure.
>
>
>
>
>-Bertrand

Re: URLResource reading from svn.apache.org by default?

Posted by Werner Keil <we...@gmail.com>.
1) The url has to contain the major version number (ex: ../v1/.., ../v2/..,
../v3/..). This allows for different client versions to work against their
supported data. Not sure if maven supports this OOTB or if we just release
our own major version LATEST.

Without changing the POM if you wanted Maven to switch between /v1, /v2 or
/v3 that would require either user specific properties overriding the
project specific one or one could call different profiles.


On Fri, Jul 18, 2014 at 4:07 PM, Reza <re...@yahoo.com.invalid>
wrote:

> Is that URL HTTP?
>
> Currently there are 2 requirements for downloading devicemap resources
> over the internet:
>
> 1) The url has to contain the major version number (ex: ../v1/..,
> ../v2/.., ../v3/..). This allows for different client versions to work
> against their supported data. Not sure if maven supports this OOTB or if we
> just release our own major version LATEST.
>
> 2) The download has to be fast. Don't want initialization taking more than
> 1 to 2 seconds. Putting a CDN infront of the URL will solve this.
>
> Am I missing anything else...?
>
>
> ________________________________
>  From: Bertrand Delacretaz <bd...@apache.org>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> Sent: Friday, July 18, 2014 9:38 AM
> Subject: Re: URLResource reading from svn.apache.org by default?
>
>
> Hi,
>
> On Fri, Jul 18, 2014 at 3:06 PM, Reza <re...@yahoo.com.invalid>
> wrote:
> > ...a common complaint about using device classification is that you have
> to
> > constantly track and maintain new devices...
>
> You might also use the Maven distribution mechanism for these data
> files - in another project I'm using pax URL to resolve URLs like
>
> mvn:org.apache.sling/org.apache.sling.commons.log/LATEST
>
> to get the corresponding artifact from a Maven repository.
>
> The nice thing with that is that you don't have to worry about
> infrastructure.
>
>
>
>
> -Bertrand
>

Re: URLResource reading from svn.apache.org by default?

Posted by Reza <re...@yahoo.com.INVALID>.
Is that URL HTTP?

Currently there are 2 requirements for downloading devicemap resources over the internet:

1) The url has to contain the major version number (ex: ../v1/.., ../v2/.., ../v3/..). This allows for different client versions to work against their supported data. Not sure if maven supports this OOTB or if we just release our own major version LATEST.

2) The download has to be fast. Don't want initialization taking more than 1 to 2 seconds. Putting a CDN infront of the URL will solve this.

Am I missing anything else...?


________________________________
 From: Bertrand Delacretaz <bd...@apache.org>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com> 
Sent: Friday, July 18, 2014 9:38 AM
Subject: Re: URLResource reading from svn.apache.org by default?
 

Hi,

On Fri, Jul 18, 2014 at 3:06 PM, Reza <re...@yahoo.com.invalid> wrote:
> ...a common complaint about using device classification is that you have to
> constantly track and maintain new devices...

You might also use the Maven distribution mechanism for these data
files - in another project I'm using pax URL to resolve URLs like

mvn:org.apache.sling/org.apache.sling.commons.log/LATEST

to get the corresponding artifact from a Maven repository.

The nice thing with that is that you don't have to worry about infrastructure.




-Bertrand

Re: URLResource reading from svn.apache.org by default?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,

On Fri, Jul 18, 2014 at 3:06 PM, Reza <re...@yahoo.com.invalid> wrote:
> ...a common complaint about using device classification is that you have to
> constantly track and maintain new devices...

You might also use the Maven distribution mechanism for these data
files - in another project I'm using pax URL to resolve URLs like

 mvn:org.apache.sling/org.apache.sling.commons.log/LATEST

to get the corresponding artifact from a Maven repository.

The nice thing with that is that you don't have to worry about infrastructure.

-Bertrand

Re: URLResource reading from svn.apache.org by default?

Posted by Reza <re...@yahoo.com.INVALID>.
Cool. My motivation was that the URL loading method would track the latest changes very closely... maybe that was a little bit too close :)

So a common complaint about using device classification is that you have to constantly track and maintain new devices. If the client is configured to load via URL, that removes this burden from the user. Whenever the client is instantiated, it grabs the latest version matched data. Also, if you load from URL, you dont need the devicemap-data jar dependency, but it might be safe to include as a fallback. This stuff should probably be documented...

I actually made a task to fix this cause I had an uneasy feeling putting the SVN url in the code:

https://issues.apache.org/jira/browse/DMAP-41


Also, here is the branch for 1.0.1 changes:

http://svn.apache.org/viewvc/incubator/devicemap/branches/devicemap-java-client-1.0.1/


I already updated trunk to 1.1.0-SNAPSHOT.


________________________________
 From: Bertrand Delacretaz <bd...@apache.org>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org> 
Sent: Friday, July 18, 2014 8:18 AM
Subject: Re: URLResource reading from svn.apache.org by default?
 

On Fri, Jul 18, 2014 at 1:33 PM, Reza <re...@yahoo.com.invalid> wrote:
> ...What we can do is this, keep 1.0.0 for voting only. If and when that passes,
> we can patch the url and immediately releases a 1.0.1 and that release will
> be made available to the public...

Works for me!


-Bertrand

Re: URLResource reading from svn.apache.org by default?

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jul 18, 2014 at 1:33 PM, Reza <re...@yahoo.com.invalid> wrote:
> ...What we can do is this, keep 1.0.0 for voting only. If and when that passes,
> we can patch the url and immediately releases a 1.0.1 and that release will
> be made available to the public...

Works for me!

-Bertrand

Re: URLResource reading from svn.apache.org by default?

Posted by Reza <re...@yahoo.com.INVALID>.
Ahh.. yes, forgot about that. Meant to move that to our vm.

What we can do is this, keep 1.0.0 for voting only. If and when that passes, we can patch the url and immediately releases a 1.0.1 and that release will be made available to the public.

Does that work?