On Mon, Nov 8, 2010 at 10:21 PM, David Overcash
wrote:
>> Hm, don't understand, why you want to reinvent the wheel, when WebDAV
>> exists.
>
> To me it seems that it would make mobile development much easier. Then
> again, I have yet to try with WebDAV.
> It's just that WebDAV (in a sense) has al
>
> Hm, don't understand, why you want to reinvent the wheel, when WebDAV
> exists.
>
To me it seems that it would make mobile development much easier. Then
again, I have yet to try with WebDAV.
It's just that WebDAV (in a sense) has already tried to reinvent the wheel -
and all that is necessar
On Sat, Nov 6, 2010 at 12:15 PM, Troy A. Griffitts wrote:
> On 11/06/2010 04:36 AM, Nic Carter wrote:
>
>> I initially submitted a patch for HTTP parsing, but it only
>> works for CrossWire and not for the Bible.org nor for the Xiphos
>> repos, and I have no intention of modifying the parsing code
On Fri, Nov 5, 2010 at 4:51 PM, David Overcash wrote:
>>
>> Our current reasons to switch to HTTP is that HTTP is ubiquitous-- often
>> already available at institutions, usually requires no additional
>> training to make something available, and has no firewall/security
>> concerns. I wonder if
On Mon, Nov 8, 2010 at 11:09 PM, DM Smith wrote:
> InstallSize doesn't give the download size. HEAD does. For compressed
> modules and image modules these are fairly close. InstallSize is also fairly
> recent and not all confs have it. So if our software did use it, it'd have
> too fall back to an
InstallSize doesn't give the download size. HEAD does. For compressed modules
and image modules these are fairly close. InstallSize is also fairly recent and
not all confs have it. So if our software did use it, it'd have too fall back
to another way when not there.
Doing HEAD on all the part
Just recall that HEAD presumably takes another roundtrip to the server,
adding latency, while InstallSize just requires you to have the conf files
you have probably already got. (In reality, it's probably not that much of
a problem, but I'm obviously feeling paranoid about latency today ;) ).
Jon
Yes, do a HEAD request and then look at the Content-Length header.
On Sun, Nov 7, 2010 at 1:11 PM, DM Smith wrote:
>
>
> On Nov 6, 2010, at 10:22 PM, Nic Carter wrote:
>
> > But, I believe there is a way of telling the size of a file being
> retrieved via HTTP GET? hopefully we could use that
On Nov 6, 2010, at 10:22 PM, Nic Carter wrote:
> But, I believe there is a way of telling the size of a file being retrieved
> via HTTP GET? hopefully we could use that as well? :)
IIRC, it's HEAD. JSword uses it. Works well.
In Him,
DM
>From my phone.
Actually, directory indexes are standardized in WebDAV. If the problem with
using HTTP is that the directory listings aren't provided in a standardized
format across Apache and IIS but rather are in a sort of ad hoc HTML format,
a solution could be to provide a custom directory index handler that r
Thanks for the long reply. :) It is frustrating that some things are designed
really well and other bits are painful, like getting a listing of files...
ok, so, I did take a quick look at my code and one way of fixing the Xiphos
listing, for example, is by not trying to parse the file sizes.
On 11/06/2010 04:36 AM, Nic Carter wrote:
> I initially submitted a patch for HTTP parsing, but it only
> works for CrossWire and not for the Bible.org nor for the Xiphos
> repos, and I have no intention of modifying the parsing code even
> more in order to try to support more web servers!
:) tha
>
>
> Our current reasons to switch to HTTP is that HTTP is ubiquitous-- often
> already available at institutions, usually requires no additional
> training to make something available, and has no firewall/security
> concerns. I wonder if WebDAV still gives us those benefits.
>
Sorry - coming in
On Fri, Nov 5, 2010 at 10:25 AM, Troy A. Griffitts wrote:
> Thanks for the suggestion Weston,
>
> I had no idea WebDAV allowed programmatic traversal of remote content.
> That's great to know!
>
> I wonder at the value of depending on WebDAV to solve our problem though.
Every hosting provider I k
Thanks for the suggestion Weston,
I had no idea WebDAV allowed programmatic traversal of remote content.
That's great to know!
I wonder at the value of depending on WebDAV to solve our problem though.
Our current reasons to switch to HTTP is that HTTP is ubiquitous-- often
already available at i
15 matches
Mail list logo
