Web arxiv reader (dailyarxiv.com) [Was API & JSONP]
Juan Jose Garcia-Ripoll
On Sat, Mar 26, 2011 at 4:19 AM, Juan Jose Garcia-Ripoll
<juanjose.g...@googlemail.com> wrote:
thanks for the link. With the capability to provide daily listings for
any given day and subject area this certainly provides some
functionality that is not readily available at arXiv (some ground is
covered by the /new and /recent listings and the /catchup interface).
There are various reasons that motivated me to do this
- catching up when being off-line several days is hard in the current system.
- combining RSS from different tags leads to duplicates and is hard to read.
- the lists provided by arxiv.org are too long for me: I do not need the abstract unless I decide that the work is related to my field.
- listing multiple subcategories at the same time, removing those which are not wanted
- slightly more readable formats and fonts (still playing with it)
- reading on mobile devices (specialized pages for iPod, iPhone, Android)
On the line, but yet to be precised
- sharing via email, scirate, facebook, etc.
- marking articles for later operation (sharing, retreiving, forwarding...)
- defaulting automatically to mirrors for PDF downloading (help here?)
Problems right now
- queries take a long time (1 to 2 seconds) due to the proxy. serving webpages in my provider is pretty fast, but the php script that acts as a proxy is sloooow. I believe its outward bandwidth is capped by the provider. This might be solved by json
- on mobile devices, when you leave the page for reading a PDF and return, the browser reloads the page, which means another 1s delay and yet another query.
- no caching of queries. I can not do that right now because my web account does not have a private server, nor memcache, nor anything near that intelligent. Does the arXiv do this?
- right now it only uses submission dates. I plan to add an option to consider all updates (it is unfortunate that cross listings can not be distinguished from minor updates)
- maybe some server-side "memory" is needed. Currently all options are stored as cookies which means that on going to a different computer the user has to choose dates and selections again.
- not thoroughly tested.
If you wish I can put a link up at http://arxiv.org/help/api/index#community
Feel free to do it!
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
Thorsten S
<juanjose.g...@googlemail.com> wrote:
> On Tue, Mar 29, 2011 at 3:07 AM, Thorsten S <thorsten....@gmail.com>
> wrote:
>>
>> On Sat, Mar 26, 2011 at 4:19 AM, Juan Jose Garcia-Ripoll
>> <juanjose.g...@googlemail.com> wrote:
>> > This is the final web
>> >
>> > http://dailyarxiv.com/
>>
>> thanks for the link. With the capability to provide daily listings for
>> any given day and subject area this certainly provides some
>> functionality that is not readily available at arXiv (some ground is
>> covered by the /new and /recent listings and the /catchup interface).
>
> There are various reasons that motivated me to do this
>
> - catching up when being off-line several days is hard in the current
> system.
no, there is the /catchup form especially for this purpose, e.g.
http://arxiv.org/multi?group=grp_physics&%2Fcatchup=Catchup
> - combining RSS from different tags leads to duplicates and is hard to read.
> - the lists provided by arxiv.org are too long for me: I do not need the
> abstract unless I decide that the work is related to my field.
the weekly listings do not have the abstract, e.g.
http://arxiv.org/list/astro-ph.CO/recent
and obviously that allows you to do individual subcategory browsing
> - listing multiple subcategories at the same time, removing those which are
> not wanted
agreed
> - slightly more readable formats and fonts (still playing with it)
that's a style choice and it's one reason we encourage overlays. you
are free to mangle the data into any form you like
> - reading on mobile devices (specialized pages for iPod, iPhone, Android)
agreed, although with the multitude of devices, screen sizes, etc,
there is no one size fits all solution and it is also a style question
>
> On the line, but yet to be precised
>
> - sharing via email, scirate, facebook, etc.
> - marking articles for later operation (sharing, retreiving, forwarding...)
> - defaulting automatically to mirrors for PDF downloading (help here?)
>
> Problems right now
>
> - queries take a long time (1 to 2 seconds) due to the proxy. serving
> webpages in my provider is pretty fast, but the php script that acts as a
> proxy is sloooow.
why php?
> I believe its outward bandwidth is capped by the provider.
> This might be solved by json
or hosting the service in the cloud
> - on mobile devices, when you leave the page for reading a PDF and return,
> the browser reloads the page, which means another 1s delay and yet another
> query.
> - no caching of queries. I can not do that right now because my web account
> does not have a private server, nor memcache, nor anything near that
> intelligent. Does the arXiv do this?
not memcache, but home brew query caching
> - right now it only uses submission dates. I plan to add an option to
> consider all updates (it is unfortunate that cross listings can not be
> distinguished from minor updates)
> - maybe some server-side "memory" is needed. Currently all options are
> stored as cookies which means that on going to a different computer the user
> has to choose dates and selections again.
or share her browser settings across devices with one of many services/tools
> - not thoroughly tested.
>
>> If you wish I can put a link up at
>> http://arxiv.org/help/api/index#community
>
> Feel free to do it!
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
>
Cheers
T.