Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of santiago.gala@gmail.com
 designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F753214-CE0B-4A79-9AC1-19E86901638E@adobe.com>
References: 
 <CAPXTYCUjVYJxsMCaJCTe2rYAqQnLOtLv3SwU5pOV8++D8-s21g@mail.gmail.com>
	<9C0FC4C8E9C29945B01766FC7F9D389818A7A2BE5E@eurmbx01.eur.adobe.com>
	<loom.20131010T162255-267@post.gmane.org>
	<9C0FC4C8E9C29945B01766FC7F9D389818A7A2C012@eurmbx01.eur.adobe.com>
	<CAPXTYCX=cq_imfYAM0wPxoj5NhBbhUW8SKW7jJNrjUkoCjhrRQ@mail.gmail.com>
	<525D1491.7030206@gmx.de>
	<CAPXTYCUTYjfJYA3wLc0r7J5FbVaVUDx60H9BnDdcfrxAi9kMLw@mail.gmail.com>
	<7869D6FC-1BDD-4B52-813F-088B07D7CBF2@adobe.com>
	<CAPXTYCWM2oqRbUJHF=E52LHMC478EunbPNN-g2f7NrOFiG928Q@mail.gmail.com>
	<CAC8ULPbLz3hU_aP2mwDzkYDtPVO8H7TjuJV5E6SjHrQsyvkJTw@mail.gmail.com>
	<CAPXTYCVhiuN6bwKQ8_wWa3q48UuaC2JJs6zS5LeW5KyLCYxy3w@mail.gmail.com>
	<CAC8ULPZq7Wf2KZpPNAdBB5Po_yPogFGJ8uyze4j3D0_gjsBhrg@mail.gmail.com>
	<CAPXTYCUodD6WdyTRJ8FJb7nox_En8OXMbFQ8uXD95b+TG=T0aA@mail.gmail.com>
	<4F753214-CE0B-4A79-9AC1-19E86901638E@adobe.com>
Date: Thu, 24 Oct 2013 17:02:51 +0200
Message-ID: 
 <CAPXTYCX1JXYSkubBWfe5DO8M6M0-cCGyfw=A35SoErzRQ047jw@mail.gmail.com>
Subject: Re: Evaluating jackrabbit use for media content
From: Santiago Gala <santiago.gala@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: multipart/alternative; boundary=e89a8fb1fbfe7a029c04e97dedc1

--e89a8fb1fbfe7a029c04e97dedc1
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 24, 2013 at 12:24 AM, Alexander Klimetschek
<aklimets@adobe.com>wrote:

> On 23.10.2013, at 08:00, Santiago Gala <santiago.gala@gmail.com> wrote:
> > With this caveat, multi byterange support does not look like it is
> working.
> > My second test:
> >
> > $ curl -v -u admin:admin -H "Range: bytes=0-20,21-63"
> > http://localhost:8080/index.html
> > ....
> > As curl points, the response has no chunk transfer encoding, no
> > Content-Length, no "Connection: close". This is violation of HTTP, one of
> > the three things is required or the client gets confused, as you see here
> > (I had to use Ctrl-C to make the test end).
>
> Ok, you might want to report the issue with multi-byte requests on
> https://issues.apache.org/jira/browse/SLING, thanks! AFAIK, the code was
> taken from Apache Tomcat, and was considered stable, but you never know.
>

The issue is not with sling, but with curl. A multipart/* entity is
properly delimited, the --delimiter-- token marks end of it, as RFC2616
clearly says: "Unlike in RFC 2046, the epilogue of any multipart message
MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if
the original multipart contains an epilogue). These restrictions exist in
order to preserve the self-delimiting nature of a multipart message- body,
wherein the "end" of the message-body is indicated by the ending multipart
boundary."

 I'm looking for the place to report it to curl so that it correctly
interprets the end boundary as ending a multipart HTTP response...

>
> The common single-range support should work fine though, we use that here.
> One important use case was html5 video, where browsers use http ranges for
> progressive streaming, and that works well.
>

This is the main case we need to support, nice to know that it has already
been tested to work. :)


>
> > I stilll need to find out if handling of binaries is done
> > efficiently, without copying to java.io.tmpdir or reading into memory,
> and
> > a number of other tests.
>
> It does not create a temp file, it uses InputStream.skip() (see
> StreamRendererServlet#copyRange) to get the ranges, which in case of a
> FileDataStore in Jackrabbit boils down to a random access on the underlying
> file. Pretty efficient.
>
>
Cool. We will quite possibly use JCR for the metainformation, and a
separate PUT request to fill the video in, or GET to read it, so I'm no
longer much concerned about the copying of binaries between client and
server done by jackrabbit remoting in java code...


> > Also, sling has way too many dependencies that are
> > completely out of scope for our requirements, and getting it trimmed down
> > to something about the size of jackrabbit would be needed...
>
> I understand - if that's the only reason you'd need Sling for, this is
> probably overkill. You might be able to take the code as an example for a
> custom servlet. OTOH, if you are doing web app stuff on top of JCR, Sling
> is really a good option - only Jackrabbit itself, even if it comes with
> WebDAV and other things, is usually pretty limiting if you want to expose
> JCR over the web. And RMI is definitely something to avoid over the network.
>
>
We are taking a look to sling, and I guess that a OSGI trimmed down sling
can work as a foundation for our media repository...


> Cheers,
> Alex


Regards, I'll keep you informed of our results
Santiago

--e89a8fb1fbfe7a029c04e97dedc1--