From ljun at real.com Sun Dec 2 21:02:08 2007
From: ljun at real.com (lijun)
Date: Sun Dec 2 20:32:10 2007
Subject: [filesystem-dev] Why '+' must be replaced by ' '?
Message-ID: <000c01c83569$aa89e0a0$6501a8c0@reallijun>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: matrix_h.263_aac_v1_176_144_25fps_48000hz_m_64+128kbp.mp3
Type: application/octet-stream
Size: 582426 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071203/1fecf1e8/matrix_h.263_aac_v1_176_144_25fps_48000hz_m_64128kbp-0001.obj
From ehyche at real.com Mon Dec 3 05:44:34 2007
From: ehyche at real.com (Eric Hyche)
Date: Mon Dec 3 05:14:11 2007
Subject: [filesystem-dev] Why '+' must be replaced by ' '?
In-Reply-To: <000c01c83569$aa89e0a0$6501a8c0@reallijun>
References: <000c01c83569$aa89e0a0$6501a8c0@reallijun>
Message-ID: <003301c835b2$a5214150$db68a8c0@EHYCHED620>
I'm not sure why it is replaced in filenames - probably to support some
legacy feature. In URLs, I believe '+' has a special meaning. Does it
work if you escape the name? For instance,
1+2.mp3 becomes 1%2B2.mp3
Eric
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc. =20
> -----Original Message-----
> From: lijun [mailto:ljun@real.com]=20
> Sent: Monday, December 03, 2007 12:02 AM
> To: filesystem-dev@helixcommunity.org
> Cc: ehyche@real.com; 'Lovish Dhawan'; 'anshuman'; 'Rishi=20
> Mathew'; 'Rahul Agarwal'
> Subject: [filesystem-dev] Why '+' must be replaced by ' '?
>=20
> Hi
>=20
> =20
>=20
> I find that helix player based on atlas310 can=A1=AFt handle=20
> filename with =A1=AE+=A1=AF symbol correctly. After debugging, I find=20
> the reason is that: in file=20
> filesystem/local/full/smplfsys.cpp function=20
> CSimpleFileObject::UpdateFileNameMember(), =A1=AE+=A1=AF is replaced =
by=20
> =A1=AE =A1=AE; in file common/util/rtsputil.cpp function=20
> URLUnescapeBuffer(), =A1=AE+=A1=AF is replaced by =A1=AE =A1=AE. When=20
> HELIX_FEATURE_MINI_SMPLFSYS isn=A1=AFt defined, smplfsys.cpp is=20
> used; when it is defined, rtsputil.cpp is used. Can anybody=20
> tell me why =A1=AE+=A1=AF must be replaced by =A1=AE =A1=AE?
>=20
> =20
>=20
> I have a phone e680i, Motorola product, using=20
> cayenne150. It can play file with =A1=AE+=A1=AF in filename.
>=20
> The attachment is file used for test. It=A1=AFs an mp3 file,=20
> name from a 3gp file. You can just use a name such as =
=A1=B01+2.mp3=A1=B1.
>=20
> Thanks.
>=20
> =20
>=20
> Best Regards
>=20
> -------------------------------------------------------
> Eric Li (=C0=EE=BE=FC)
> www.realnetworks.com
> www.helixcommunity.org
> -------------------------------------------------------
>=20
> =20
>=20
>=20
From ljun at real.com Wed Dec 5 00:23:15 2007
From: ljun at real.com (lijun)
Date: Tue Dec 4 23:52:23 2007
Subject: [filesystem-dev] Why '+' must be replaced by ' '?
In-Reply-To: <003301c835b2$a5214150$db68a8c0@EHYCHED620>
References: <000c01c83569$aa89e0a0$6501a8c0@reallijun>
<003301c835b2$a5214150$db68a8c0@EHYCHED620>
Message-ID: <00cc01c83718$18af8d00$6501a8c0@reallijun>
Hi Eric
Your method works. It's sure that the TLC must give
HXPlayer::OpenURL(const char* pURL) an escaped URL. And URL got in wm50 =
is
not escaped yet. I am working on issue of not supporting Chinese symbol. =
The
escape issue is lower priority. I think maybe next week I will solve it =
and
send out a patch.
Thanks, Eric.=20
Best Regards
Eric Li (=C0=EE=BE=FC)
=20
>-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>=B7=A2=BC=FE=C8=CB: Eric Hyche [mailto:ehyche@real.com]
>=B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA12=D4=C23=C8=D5 21:45
>=CA=D5=BC=FE=C8=CB: ljun@real.com; filesystem-dev@helixcommunity.org
>=B3=AD=CB=CD: 'Lovish Dhawan'; 'anshuman'; 'Rishi Mathew'; 'Rahul =
Agarwal'
>=D6=F7=CC=E2: RE: [filesystem-dev] Why '+' must be replaced by ' '?
>
>
>I'm not sure why it is replaced in filenames - probably to support some
>legacy feature. In URLs, I believe '+' has a special meaning. Does it
>work if you escape the name? For instance,
>
>1+2.mp3 becomes 1%2B2.mp3
>
>Eric
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>Eric Hyche (ehyche@real.com)
>Technical Lead
>RealNetworks, Inc.
>
>> -----Original Message-----
>> From: lijun [mailto:ljun@real.com]
>> Sent: Monday, December 03, 2007 12:02 AM
>> To: filesystem-dev@helixcommunity.org
>> Cc: ehyche@real.com; 'Lovish Dhawan'; 'anshuman'; 'Rishi
>> Mathew'; 'Rahul Agarwal'
>> Subject: [filesystem-dev] Why '+' must be replaced by ' '?
>>
>> Hi
>>
>>
>>
>> I find that helix player based on atlas310 can=A1=AFt handle
>> filename with =A1=AE+=A1=AF symbol correctly. After debugging, I find
>> the reason is that: in file
>> filesystem/local/full/smplfsys.cpp function
>> CSimpleFileObject::UpdateFileNameMember(), =A1=AE+=A1=AF is replaced =
by
>> =A1=AE =A1=AE; in file common/util/rtsputil.cpp function
>> URLUnescapeBuffer(), =A1=AE+=A1=AF is replaced by =A1=AE =A1=AE. When
>> HELIX_FEATURE_MINI_SMPLFSYS isn=A1=AFt defined, smplfsys.cpp is
>> used; when it is defined, rtsputil.cpp is used. Can anybody
>> tell me why =A1=AE+=A1=AF must be replaced by =A1=AE =A1=AE?
>>
>>
>>
>> I have a phone e680i, Motorola product, using
>> cayenne150. It can play file with =A1=AE+=A1=AF in filename.
>>
>> The attachment is file used for test. It=A1=AFs an mp3 file,
>> name from a 3gp file. You can just use a name such as =
=A1=B01+2.mp3=A1=B1.
>>
>> Thanks.
>>
>>
>>
>> Best Regards
>>
>> -------------------------------------------------------
>> Eric Li (=C0=EE=BE=FC)
>> www.realnetworks.com
>> www.helixcommunity.org
>> -------------------------------------------------------
>>
>>
>>
>>
From john.wei at nokia.com Wed Dec 5 11:59:01 2007
From: john.wei at nokia.com (john.wei@nokia.com)
Date: Wed Dec 5 11:29:23 2007
Subject: [Filesystem-dev] CR: Installing Asynchronous Datasource for Audio
Controller
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB04E04213@daebe102.NOE.Nokia.com>
Nokia submits this code under the terms of a commercial contribution
agreement with RealNetworks, and I am authorized to contribute this code
under said agreement."
Modified by: john.wei@nokia.com
Reviewed by:
Date: 03-Dec-2007
Project: SymbianMmf_Rel
TSW: ELDG-73WGS6
Synopsis: Installing Asynchronous Datasource for Audio Controller
Audio controller is currently using synchronous datasource for playing.
This CR changes this to asynchronous datasource, which results in audio
play more responsive. Please note that video playing is not affected.
Files Modified:
/cvsroot/common/fileio/pub/hxdatasource.h
/cvsroot/common/fileio/hxdatasource.cpp
/cvsroot/common/fileio/symbian.pcf
/cvsroot/common/fileio/platform/symbian/HxMMDataSource.cpp
/cvsroot/common/fileio/pub/platform/symbian/HxMMDataSource.h
/cvsroot/clientapps/symbianMmf/audiocontroller/hxmmfaudioctrl.cpp
/cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.cpp
/cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.h
/cvsroot/filesystem/local/mini/minifileobj.cpp
/cvsroot/common/include/ihxmmfdatasource.h
Files New:
/cvsroot/common/fileio/platform/symbian/asynchronousmultireader.cpp
/cvsroot/common/fileio/pub/platform/symbian/asynchronousmultireader.h
Image Size and Heap Use impact: minor
Module Release testing (STIF) : N/A
Test case(s) Added : no
Memory leak check performed : Yes. No new leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Head & 210CayS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asynchronousmultireader.cpp
Type: application/octet-stream
Size: 42727 bytes
Desc: asynchronousmultireader.cpp
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071205/61266c35/asynchronousmultireader-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asynchronousmultireader.h
Type: application/octet-stream
Size: 16621 bytes
Desc: asynchronousmultireader.h
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071205/61266c35/asynchronousmultireader-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileio.diff
Type: application/octet-stream
Size: 6025 bytes
Desc: fileio.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071205/61266c35/fileio-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: include.diff
Type: application/octet-stream
Size: 1671 bytes
Desc: include.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071205/61266c35/include-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mini.diff
Type: application/octet-stream
Size: 2165 bytes
Desc: mini.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071205/61266c35/mini-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mmf.diff
Type: application/octet-stream
Size: 2858 bytes
Desc: mmf.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071205/61266c35/mmf-0001.obj
From john.wei at nokia.com Thu Dec 6 13:26:43 2007
From: john.wei at nokia.com (john.wei@nokia.com)
Date: Thu Dec 6 12:56:01 2007
Subject: [Filesystem-dev] Resend CR: Installing Asynchronous Datasource for
Audio Controller
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB04E3ED28@daebe102.NOE.Nokia.com>
Nokia submits this code under the terms of a commercial contribution
agreement with RealNetworks, and I am authorized to contribute this code
under said agreement."
Modified by: john.wei@nokia.com
Reviewed by:
Date: 03-Dec-2007
Project: SymbianMmf_Rel
TSW: ELDG-73WGS6
Synopsis: Installing Asynchronous Datasource for Audio Controller
Audio controller is currently using synchronous datasource for playing.
This CR changes this to asynchronous datasource, which results in audio
play more responsive. Please note that video playing is not affected.
Files Modified:
/cvsroot/common/fileio/pub/hxdatasource.h
/cvsroot/common/fileio/hxdatasource.cpp
/cvsroot/common/fileio/symbian.pcf
/cvsroot/common/fileio/platform/symbian/HxMMDataSource.cpp
/cvsroot/common/fileio/pub/platform/symbian/HxMMDataSource.h
/cvsroot/clientapps/symbianMmf/audiocontroller/hxmmfaudioctrl.cpp
/cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.cpp
/cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.h
/cvsroot/filesystem/local/mini/minifileobj.cpp
/cvsroot/common/include/ihxmmfdatasource.h
Files New:
/cvsroot/common/fileio/platform/symbian/asynchronousmultireader.cpp
/cvsroot/common/fileio/pub/platform/symbian/asynchronousmultireader.h
Image Size and Heap Use impact: minor
Module Release testing (STIF) : N/A
Test case(s) Added : no
Memory leak check performed : Yes. No new leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Head & 210CayS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asynchronousmultireader.cpp
Type: application/octet-stream
Size: 42727 bytes
Desc: asynchronousmultireader.cpp
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071206/db7336d2/asynchronousmultireader-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asynchronousmultireader.h
Type: application/octet-stream
Size: 16621 bytes
Desc: asynchronousmultireader.h
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071206/db7336d2/asynchronousmultireader-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileio.diff
Type: application/octet-stream
Size: 6025 bytes
Desc: fileio.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071206/db7336d2/fileio-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: include.diff
Type: application/octet-stream
Size: 1671 bytes
Desc: include.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071206/db7336d2/include-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mini.diff
Type: application/octet-stream
Size: 2165 bytes
Desc: mini.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071206/db7336d2/mini-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mmf.diff
Type: application/octet-stream
Size: 2858 bytes
Desc: mmf.diff
Url : http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071206/db7336d2/mmf-0001.obj
From gwright at real.com Fri Dec 7 10:33:12 2007
From: gwright at real.com (Greg Wright)
Date: Fri Dec 7 10:01:38 2007
Subject: [Filesystem-dev] Re: Resend CR: Installing Asynchronous Datasource
for Audio Controller
In-Reply-To: <1F7C330B210B764DBBE8B2D749F9A5DB04E3ED28@daebe102.NOE.Nokia.com>
References: <1F7C330B210B764DBBE8B2D749F9A5DB04E3ED28@daebe102.NOE.Nokia.com>
Message-ID: <475991E8.9060304@real.com>
Looks good.
--greg.
john.wei@nokia.com wrote:
> Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this code
> under said agreement."
>
> Modified by: john.wei@nokia.com
>
> Reviewed by:
>
> Date: 03-Dec-2007
>
> Project: SymbianMmf_Rel
>
> TSW: ELDG-73WGS6
>
> Synopsis: Installing Asynchronous Datasource for Audio Controller
>
> Audio controller is currently using synchronous datasource for playing.
> This CR changes this to asynchronous datasource, which results in audio
> play more responsive. Please note that video playing is not affected.
>
> Files Modified:
>
> /cvsroot/common/fileio/pub/hxdatasource.h
> /cvsroot/common/fileio/hxdatasource.cpp
> /cvsroot/common/fileio/symbian.pcf
> /cvsroot/common/fileio/platform/symbian/HxMMDataSource.cpp
> /cvsroot/common/fileio/pub/platform/symbian/HxMMDataSource.h
> /cvsroot/clientapps/symbianMmf/audiocontroller/hxmmfaudioctrl.cpp
> /cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.cpp
> /cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.h
> /cvsroot/filesystem/local/mini/minifileobj.cpp
> /cvsroot/common/include/ihxmmfdatasource.h
>
> Files New:
> /cvsroot/common/fileio/platform/symbian/asynchronousmultireader.cpp
> /cvsroot/common/fileio/pub/platform/symbian/asynchronousmultireader.h
>
> Image Size and Heap Use impact: minor
>
> Module Release testing (STIF) : N/A
>
> Test case(s) Added : no
>
> Memory leak check performed : Yes. No new leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Head & 210CayS
From john.wei at nokia.com Fri Dec 7 13:03:40 2007
From: john.wei at nokia.com (john.wei@nokia.com)
Date: Fri Dec 7 12:32:39 2007
Subject: [Filesystem-dev] RE: Resend CR: Installing Asynchronous Datasource
for Audio Controller
In-Reply-To: <475991E8.9060304@real.com>
References: <1F7C330B210B764DBBE8B2D749F9A5DB04E3ED28@daebe102.NOE.Nokia.com>
<475991E8.9060304@real.com>
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB04E3F42C@daebe102.NOE.Nokia.com>
Thanks. Codes have been checked into both Head and Cayes210.
-----Original Message-----
From: ext Greg Wright [mailto:gwright@real.com]
Sent: Friday, December 07, 2007 12:33 PM
To: Wei John (Nokia-TP-MSW/Dallas)
Cc: common-dev@helixcommunity.org; clientapps-dev@helixcommunity.org;
filesystem-dev@helixcommunity.org; ehyche@real.com
Subject: Re: Resend CR: Installing Asynchronous Datasource for Audio
Controller
Looks good.
--greg.
john.wei@nokia.com wrote:
> Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by: john.wei@nokia.com
>
> Reviewed by:
>
> Date: 03-Dec-2007
>
> Project: SymbianMmf_Rel
>
> TSW: ELDG-73WGS6
>
> Synopsis: Installing Asynchronous Datasource for Audio Controller
>
> Audio controller is currently using synchronous datasource for
playing.
> This CR changes this to asynchronous datasource, which results in
> audio play more responsive. Please note that video playing is not
affected.
>
> Files Modified:
>
> /cvsroot/common/fileio/pub/hxdatasource.h
> /cvsroot/common/fileio/hxdatasource.cpp
> /cvsroot/common/fileio/symbian.pcf
> /cvsroot/common/fileio/platform/symbian/HxMMDataSource.cpp
> /cvsroot/common/fileio/pub/platform/symbian/HxMMDataSource.h
> /cvsroot/clientapps/symbianMmf/audiocontroller/hxmmfaudioctrl.cpp
> /cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.cpp
> /cvsroot/clientapps/symbianMmf/common/hxmmfbasectrl.h
> /cvsroot/filesystem/local/mini/minifileobj.cpp
> /cvsroot/common/include/ihxmmfdatasource.h
>
> Files New:
> /cvsroot/common/fileio/platform/symbian/asynchronousmultireader.cpp
> /cvsroot/common/fileio/pub/platform/symbian/asynchronousmultireader.h
>
> Image Size and Heap Use impact: minor
>
> Module Release testing (STIF) : N/A
>
> Test case(s) Added : no
>
> Memory leak check performed : Yes. No new leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Head & 210CayS
From asingh at real.com Thu Dec 13 05:16:48 2007
From: asingh at real.com (Anshuman Singh)
Date: Thu Dec 13 04:43:26 2007
Subject: [Filesystem-dev] Query regarding a pd content
Message-ID: <476130C0.2020800@real.com>
Hi,
How does helix handle the progressively downloading content with
unknown size or without "?filesize=" in URL ?
Please provide some information on it.
Thanks
Anshuman
From ehyche at real.com Thu Dec 13 12:03:46 2007
From: ehyche at real.com (Eric Hyche)
Date: Thu Dec 13 11:30:42 2007
Subject: [Filesystem-dev] Query regarding a pd content
In-Reply-To: <476130C0.2020800@real.com>
References: <476130C0.2020800@real.com>
Message-ID: <00d801c83dc3$451cede0$6b80a8c0@EHYCHED620>
Here's a general description of how the code
in filesystem/local/full works regarding
progressive download. Hopefully this is
what you are looking for.
The IHXFileObject uses another object (IHXDataFile)
to actually read the file. The IHXFileObject is
an asynchronous interface while IHXDataFile is
a synchronous interface.
- When the IHXDataFile is opened, its size is checked.
- As long as a read from the IHXDataFile never
fails, then a progressively downloaded file operates
exactly like a non-progressively-downloaded file.
- If a read fails, then we ask the file format
plugin to see whether or not it can handle a failed
read. In most cases, the file format says no, it
can't handle a failed read. In that case, we set
a callback for a certain number of milliseconds.
- When the callback fires, we check the filesize again
and try the read again. If the read succeeds, then
we return it. If the read fails, then we set another
callback.
- Eventually, when the size doesn't change for a long
enough period of time, then we assume the download
has finished.
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: filesystem-dev-bounces@helixcommunity.org
> [mailto:filesystem-dev-bounces@helixcommunity.org] On Behalf
> Of Anshuman Singh
> Sent: Thursday, December 13, 2007 8:17 AM
> To: filesystem-dev@helixcommunity.org
> Cc: helix-client-dev@helixcommunity.org
> Subject: [Filesystem-dev] Query regarding a pd content
>
> Hi,
>
> How does helix handle the progressively downloading
> content with
> unknown size or without "?filesize=" in URL ?
>
> Please provide some information on it.
>
>
> Thanks
> Anshuman
>
> _______________________________________________
> Filesystem-dev mailing list
> Filesystem-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
>
From Praveen.Thimmashetty at nokia.com Thu Dec 13 14:17:32 2007
From: Praveen.Thimmashetty at nokia.com (Praveen.Thimmashetty@nokia.com)
Date: Thu Dec 13 13:45:02 2007
Subject: [Filesystem-dev] How do we find out the mime type when URL doesn't
contain file extension?
Message-ID: <2A15C07EF7DF6243A092FB438FD4B36697D1C9@daebe103.NOE.Nokia.com>
> I am trying to get shout cast links(most of them don't have file
> extension as a part of url eg: http://195.214.242.74:8000 ) working on
> helix.
>
> In httpfilesys, once we get 200 OK then content-type and mime type
> pair values are set by the httpfilesys on the response header. Hence
> Hxfilesource can use these values to know the mime type during extend
> setup.
>
> HxFileSource instantiates httpfilesys during setup and while doing
> extended Setup, it looks for content type and mime type value pair
> provided by the httpfilesys. If these values are existing, then Url is
> taken care without looking for file extension.
>
> But in httpfilesys we get 200 OK only during finish Setup. Hence
> httpfilesys can provided these content type and mime type value only
> after filesource done with extended setup.
>
> how exactly are we handling this case?
>
> Thanks
> Praveen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/filesystem-dev/attachments/20071213/17fbf9eb/attachment.html
From ehyche at real.com Thu Dec 13 16:14:03 2007
From: ehyche at real.com (Eric Hyche)
Date: Thu Dec 13 15:40:57 2007
Subject: [Filesystem-dev] RE: [Client-dev] How do we find out the mime type
when URL doesn'tcontain file extension?
In-Reply-To: <2A15C07EF7DF6243A092FB438FD4B36697D1C2@daebe103.NOE.Nokia.com>
References: <2A15C07EF7DF6243A092FB438FD4B36697D1C2@daebe103.NOE.Nokia.com>
Message-ID: <011401c83de6$3c424e90$6b80a8c0@EHYCHED620>
Are you saying there is no Content-Type in
the HTTP response? Or that the Content-Type is
present, but it's still not recognizing the
mime type?
Are you using the httplite file object (filesystem/httplite)
or the full http file object (filesystem/http)?
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: client-dev-bounces@helixcommunity.org
> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> Praveen.Thimmashetty@nokia.com
> Sent: Thursday, December 13, 2007 5:08 PM
> To: client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> Subject: [Client-dev] How do we find out the mime type when
> URL doesn'tcontain file extension?
>
> I am trying to get shout cast links(most of them don't have
> file extension as a part of url eg:
> http://195.214.242.74:8000 )
> working on helix.
>
> In httpfilesys, once we get 200 OK then content-type and mime
> type pair values are set by the httpfilesys on the response
> header. Hence Hxfilesource can use these values to know the
> mime type during extend setup.
>
> HxFileSource instantiates httpfilesys during setup and while
> doing extended Setup, it looks for content type and mime type
> value pair provided by the httpfilesys. If these values are
> existing, then Url is taken care without looking for file extension.
>
> But in httpfilesys we get 200 OK only during finish Setup.
> Hence httpfilesys can provided these content type and mime
> type value only after filesource done with extended setup.
>
> how exactly are we handling this case?
>
> Thanks
> Praveen
>
>
From Praveen.Thimmashetty at nokia.com Fri Dec 14 08:22:15 2007
From: Praveen.Thimmashetty at nokia.com (Praveen.Thimmashetty@nokia.com)
Date: Fri Dec 14 07:49:13 2007
Subject: [Filesystem-dev] RE: [Client-dev] How do we find out the mime type
when URL doesn'tcontain file extension?
In-Reply-To: <011401c83de6$3c424e90$6b80a8c0@EHYCHED620>
References: <2A15C07EF7DF6243A092FB438FD4B36697D1C2@daebe103.NOE.Nokia.com>
<011401c83de6$3c424e90$6b80a8c0@EHYCHED620>
Message-ID: <2A15C07EF7DF6243A092FB438FD4B36697D2F4@daebe103.NOE.Nokia.com>
Hi Eric,
I am talking about filesystem/http.
HxFilesource loads httpfilesys and looks for content type values from
the filesystem to find out the mime type. If these values are not
present it goes and creates the file recognizer to know the mime type.
While handling shoutcast links, httpfilesys is providing content type
values. Hence there is no need to create the file recognizer to know the
mime type. hence looking for the file extension is avoided.
My question is httpfilesys can provide content type values to
Hxfilesource only after httpfilesys receives 200 OK response. Http
response header has this value.
But this response comes to httpfilesys only after hxfilesource finishes
with checking the content type values from httpfilesys. Hence
hxfilesource doesn't know about the content type values at the right
time. hxfilesource goes and creates the file recognizer to know the mime
type which will look for the file extension.
I am not clear about how exactly are we taking care of url which doesn't
have file extension.
Thanks
Praveen
-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com]
Sent: Thursday, December 13, 2007 6:14 PM
To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas);
client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
Subject: RE: [Client-dev] How do we find out the mime type when URL
doesn'tcontain file extension?
Are you saying there is no Content-Type in the HTTP response? Or that
the Content-Type is present, but it's still not recognizing the mime
type?
Are you using the httplite file object (filesystem/httplite) or the full
http file object (filesystem/http)?
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: client-dev-bounces@helixcommunity.org
> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> Praveen.Thimmashetty@nokia.com
> Sent: Thursday, December 13, 2007 5:08 PM
> To: client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> Subject: [Client-dev] How do we find out the mime type when URL
> doesn'tcontain file extension?
>
> I am trying to get shout cast links(most of them don't have file
> extension as a part of url eg:
> http://195.214.242.74:8000 ) working on
> helix.
>
> In httpfilesys, once we get 200 OK then content-type and mime type
> pair values are set by the httpfilesys on the response header. Hence
> Hxfilesource can use these values to know the mime type during extend
> setup.
>
> HxFileSource instantiates httpfilesys during setup and while doing
> extended Setup, it looks for content type and mime type value pair
> provided by the httpfilesys. If these values are existing, then Url is
> taken care without looking for file extension.
>
> But in httpfilesys we get 200 OK only during finish Setup.
> Hence httpfilesys can provided these content type and mime type value
> only after filesource done with extended setup.
>
> how exactly are we handling this case?
>
> Thanks
> Praveen
>
>
From ehyche at real.com Fri Dec 14 11:49:59 2007
From: ehyche at real.com (Eric Hyche)
Date: Fri Dec 14 11:16:43 2007
Subject: [Filesystem-dev] RE: [Client-dev] How do we find out the mime type
when URL doesn'tcontain file extension?
In-Reply-To: <2A15C07EF7DF6243A092FB438FD4B36697D2F4@daebe103.NOE.Nokia.com>
References: <2A15C07EF7DF6243A092FB438FD4B36697D1C2@daebe103.NOE.Nokia.com>
<011401c83de6$3c424e90$6b80a8c0@EHYCHED620>
<2A15C07EF7DF6243A092FB438FD4B36697D2F4@daebe103.NOE.Nokia.com>
Message-ID: <005f01c83e8a$83525880$db68a8c0@EHYCHED620>
Hmmm.. I don't think we've run into this problem on
desktop systems. I would think that the call to
IHXFileMimeMapper::FindMimeType() should not return
until the HTTP 200 OK is received.
When you trace through CHTTPFileObject::FindMimeType(),
which code path is taken?
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: Praveen.Thimmashetty@nokia.com
> [mailto:Praveen.Thimmashetty@nokia.com]
> Sent: Friday, December 14, 2007 11:22 AM
> To: ehyche@real.com; client-dev@helixcommunity.org;
> filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type
> when URL doesn'tcontain file extension?
>
> Hi Eric,
> I am talking about filesystem/http.
>
> HxFilesource loads httpfilesys and looks for content type values from
> the filesystem to find out the mime type. If these values are not
> present it goes and creates the file recognizer to know the
> mime type.
> While handling shoutcast links, httpfilesys is providing content type
> values. Hence there is no need to create the file recognizer
> to know the
> mime type. hence looking for the file extension is avoided.
>
> My question is httpfilesys can provide content type values to
> Hxfilesource only after httpfilesys receives 200 OK response. Http
> response header has this value.
> But this response comes to httpfilesys only after
> hxfilesource finishes
> with checking the content type values from httpfilesys. Hence
> hxfilesource doesn't know about the content type values at the right
> time. hxfilesource goes and creates the file recognizer to
> know the mime
> type which will look for the file extension.
>
> I am not clear about how exactly are we taking care of url
> which doesn't
> have file extension.
>
> Thanks
> Praveen
>
> -----Original Message-----
> From: ext Eric Hyche [mailto:ehyche@real.com]
> Sent: Thursday, December 13, 2007 6:14 PM
> To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas);
> client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type when URL
> doesn'tcontain file extension?
>
>
> Are you saying there is no Content-Type in the HTTP response? Or that
> the Content-Type is present, but it's still not recognizing the mime
> type?
>
> Are you using the httplite file object (filesystem/httplite)
> or the full
> http file object (filesystem/http)?
>
> Eric
>
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.
>
> > -----Original Message-----
> > From: client-dev-bounces@helixcommunity.org
> > [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> > Praveen.Thimmashetty@nokia.com
> > Sent: Thursday, December 13, 2007 5:08 PM
> > To: client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> > Subject: [Client-dev] How do we find out the mime type when URL
> > doesn'tcontain file extension?
> >
> > I am trying to get shout cast links(most of them don't have file
> > extension as a part of url eg:
> > http://195.214.242.74:8000 )
> working on
> > helix.
> >
> > In httpfilesys, once we get 200 OK then content-type and mime type
> > pair values are set by the httpfilesys on the response
> header. Hence
> > Hxfilesource can use these values to know the mime type
> during extend
> > setup.
> >
> > HxFileSource instantiates httpfilesys during setup and while doing
> > extended Setup, it looks for content type and mime type value pair
> > provided by the httpfilesys. If these values are existing,
> then Url is
>
> > taken care without looking for file extension.
> >
> > But in httpfilesys we get 200 OK only during finish Setup.
> > Hence httpfilesys can provided these content type and mime
> type value
> > only after filesource done with extended setup.
> >
> > how exactly are we handling this case?
> >
> > Thanks
> > Praveen
> >
> >
>
From Praveen.Thimmashetty at nokia.com Fri Dec 14 13:31:50 2007
From: Praveen.Thimmashetty at nokia.com (Praveen.Thimmashetty@nokia.com)
Date: Fri Dec 14 12:59:13 2007
Subject: [Filesystem-dev] RE: [Client-dev] How do we find out the mime type
when URL doesn'tcontain file extension?
In-Reply-To: <005f01c83e8a$83525880$db68a8c0@EHYCHED620>
References: <2A15C07EF7DF6243A092FB438FD4B36697D1C2@daebe103.NOE.Nokia.com>
<011401c83de6$3c424e90$6b80a8c0@EHYCHED620>
<2A15C07EF7DF6243A092FB438FD4B36697D2F4@daebe103.NOE.Nokia.com>
<005f01c83e8a$83525880$db68a8c0@EHYCHED620>
Message-ID: <2A15C07EF7DF6243A092FB438FD4B36697D3C7@daebe103.NOE.Nokia.com>
Hi Eric,
I am trying to add 'handling of url with no file extension' support to
filesystem/httplite. By referring to filesystem/http I found that,
filesystem itself is providing the content type value to find out the
mime type and avoid creating the file recognizer.
I don't have filesystem/http ported to platform I am working with. Hence
I can't trace the code :-(.
HxFileSource::setup -> loads httpfilesys
HxFileSource::extendedsetup -> checks for content type values from the
httpfilesys to determine mime type
HXFileSource::Finishsetup -> init the httpfilesys (httpfilesys gets 200
OK here)
Since HxFileSource handling of httpfilesys is similar for both httplite
and http, I was curious to know how filesystem/http is managing to
provide content type values during extendedsetup.
Could you suggest me a way to have this support for httplite.
Thanks
Praveen
-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com]
Sent: Friday, December 14, 2007 1:50 PM
To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas);
client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
Subject: RE: [Client-dev] How do we find out the mime type when URL
doesn'tcontain file extension?
Hmmm.. I don't think we've run into this problem on desktop systems. I
would think that the call to
IHXFileMimeMapper::FindMimeType() should not return until the HTTP 200
OK is received.
When you trace through CHTTPFileObject::FindMimeType(), which code path
is taken?
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: Praveen.Thimmashetty@nokia.com
> [mailto:Praveen.Thimmashetty@nokia.com]
> Sent: Friday, December 14, 2007 11:22 AM
> To: ehyche@real.com; client-dev@helixcommunity.org;
> filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type when URL
> doesn'tcontain file extension?
>
> Hi Eric,
> I am talking about filesystem/http.
>
> HxFilesource loads httpfilesys and looks for content type values from
> the filesystem to find out the mime type. If these values are not
> present it goes and creates the file recognizer to know the mime type.
> While handling shoutcast links, httpfilesys is providing content type
> values. Hence there is no need to create the file recognizer to know
> the mime type. hence looking for the file extension is avoided.
>
> My question is httpfilesys can provide content type values to
> Hxfilesource only after httpfilesys receives 200 OK response. Http
> response header has this value.
> But this response comes to httpfilesys only after hxfilesource
> finishes with checking the content type values from httpfilesys. Hence
> hxfilesource doesn't know about the content type values at the right
> time. hxfilesource goes and creates the file recognizer to know the
> mime type which will look for the file extension.
>
> I am not clear about how exactly are we taking care of url which
> doesn't have file extension.
>
> Thanks
> Praveen
>
> -----Original Message-----
> From: ext Eric Hyche [mailto:ehyche@real.com]
> Sent: Thursday, December 13, 2007 6:14 PM
> To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas);
> client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type when URL
> doesn'tcontain file extension?
>
>
> Are you saying there is no Content-Type in the HTTP response? Or that
> the Content-Type is present, but it's still not recognizing the mime
> type?
>
> Are you using the httplite file object (filesystem/httplite) or the
> full http file object (filesystem/http)?
>
> Eric
>
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.
>
> > -----Original Message-----
> > From: client-dev-bounces@helixcommunity.org
> > [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> > Praveen.Thimmashetty@nokia.com
> > Sent: Thursday, December 13, 2007 5:08 PM
> > To: client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> > Subject: [Client-dev] How do we find out the mime type when URL
> > doesn'tcontain file extension?
> >
> > I am trying to get shout cast links(most of them don't have file
> > extension as a part of url eg:
> > http://195.214.242.74:8000 )
> working on
> > helix.
> >
> > In httpfilesys, once we get 200 OK then content-type and mime type
> > pair values are set by the httpfilesys on the response
> header. Hence
> > Hxfilesource can use these values to know the mime type
> during extend
> > setup.
> >
> > HxFileSource instantiates httpfilesys during setup and while doing
> > extended Setup, it looks for content type and mime type value pair
> > provided by the httpfilesys. If these values are existing,
> then Url is
>
> > taken care without looking for file extension.
> >
> > But in httpfilesys we get 200 OK only during finish Setup.
> > Hence httpfilesys can provided these content type and mime
> type value
> > only after filesource done with extended setup.
> >
> > how exactly are we handling this case?
> >
> > Thanks
> > Praveen
> >
> >
>
From ehyche at real.com Fri Dec 14 13:50:28 2007
From: ehyche at real.com (Eric Hyche)
Date: Fri Dec 14 13:17:13 2007
Subject: [Filesystem-dev] RE: [Client-dev] How do we find out the mime type
when URL doesn'tcontain file extension?
In-Reply-To: <2A15C07EF7DF6243A092FB438FD4B36697D3C7@daebe103.NOE.Nokia.com>
References: <2A15C07EF7DF6243A092FB438FD4B36697D1C2@daebe103.NOE.Nokia.com>
<011401c83de6$3c424e90$6b80a8c0@EHYCHED620>
<2A15C07EF7DF6243A092FB438FD4B36697D2F4@daebe103.NOE.Nokia.com>
<005f01c83e8a$83525880$db68a8c0@EHYCHED620>
<2A15C07EF7DF6243A092FB438FD4B36697D3C7@daebe103.NOE.Nokia.com>
Message-ID: <007501c83e9b$58ac29b0$db68a8c0@EHYCHED620>
I have not looked in detail at filesystem/httplite, but
I can tell you what I think the relevant behaviors that
should match between filesystem/http and filesystem/httplite
in order for them to behave the same with regards to
the HXFileSource in the client core.
It looks like the filesystem/httplite file object does not
support IHXFileMimeMapper, which would probably make its
behavior different, since the HXFileSource will try to
QI the file object for IHXFileMimeMapper to get the mime type
if it cannot get it from the response headers.
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: Praveen.Thimmashetty@nokia.com
> [mailto:Praveen.Thimmashetty@nokia.com]
> Sent: Friday, December 14, 2007 4:32 PM
> To: ehyche@real.com; client-dev@helixcommunity.org;
> filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type
> when URL doesn'tcontain file extension?
>
> Hi Eric,
>
> I am trying to add 'handling of url with no file extension' support to
> filesystem/httplite. By referring to filesystem/http I found that,
> filesystem itself is providing the content type value to find out the
> mime type and avoid creating the file recognizer.
> I don't have filesystem/http ported to platform I am working
> with. Hence
> I can't trace the code :-(.
>
> HxFileSource::setup -> loads httpfilesys
> HxFileSource::extendedsetup -> checks for content type values from the
> httpfilesys to determine mime type
> HXFileSource::Finishsetup -> init the httpfilesys
> (httpfilesys gets 200
> OK here)
>
> Since HxFileSource handling of httpfilesys is similar for
> both httplite
> and http, I was curious to know how filesystem/http is managing to
> provide content type values during extendedsetup.
>
> Could you suggest me a way to have this support for httplite.
>
> Thanks
> Praveen
>
>
>
>
> -----Original Message-----
> From: ext Eric Hyche [mailto:ehyche@real.com]
> Sent: Friday, December 14, 2007 1:50 PM
> To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas);
> client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> Subject: RE: [Client-dev] How do we find out the mime type when URL
> doesn'tcontain file extension?
>
>
> Hmmm.. I don't think we've run into this problem on desktop systems. I
> would think that the call to
> IHXFileMimeMapper::FindMimeType() should not return until the HTTP 200
> OK is received.
>
> When you trace through CHTTPFileObject::FindMimeType(), which
> code path
> is taken?
>
> Eric
>
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.
>
> > -----Original Message-----
> > From: Praveen.Thimmashetty@nokia.com
> > [mailto:Praveen.Thimmashetty@nokia.com]
> > Sent: Friday, December 14, 2007 11:22 AM
> > To: ehyche@real.com; client-dev@helixcommunity.org;
> > filesystem-dev@helixcommunity.org
> > Subject: RE: [Client-dev] How do we find out the mime type when URL
> > doesn'tcontain file extension?
> >
> > Hi Eric,
> > I am talking about filesystem/http.
> >
> > HxFilesource loads httpfilesys and looks for content type
> values from
> > the filesystem to find out the mime type. If these values are not
> > present it goes and creates the file recognizer to know the
> mime type.
> > While handling shoutcast links, httpfilesys is providing
> content type
> > values. Hence there is no need to create the file
> recognizer to know
> > the mime type. hence looking for the file extension is avoided.
> >
> > My question is httpfilesys can provide content type values to
> > Hxfilesource only after httpfilesys receives 200 OK response. Http
> > response header has this value.
> > But this response comes to httpfilesys only after hxfilesource
> > finishes with checking the content type values from
> httpfilesys. Hence
>
> > hxfilesource doesn't know about the content type values at
> the right
> > time. hxfilesource goes and creates the file recognizer to know the
> > mime type which will look for the file extension.
> >
> > I am not clear about how exactly are we taking care of url which
> > doesn't have file extension.
> >
> > Thanks
> > Praveen
> >
> > -----Original Message-----
> > From: ext Eric Hyche [mailto:ehyche@real.com]
> > Sent: Thursday, December 13, 2007 6:14 PM
> > To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas);
> > client-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
> > Subject: RE: [Client-dev] How do we find out the mime type when URL
> > doesn'tcontain file extension?
> >
> >
> > Are you saying there is no Content-Type in the HTTP
> response? Or that
> > the Content-Type is present, but it's still not recognizing
> the mime
> > type?
> >
> > Are you using the httplite file object (filesystem/httplite) or the
> > full http file object (filesystem/http)?
> >
> > Eric
> >
> > =============================================
> > Eric Hyche (ehyche@real.com)
> > Technical Lead
> > RealNetworks, Inc.
> >
> > > -----Original Message-----
> > > From: client-dev-bounces@helixcommunity.org
> > > [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> > > Praveen.Thimmashetty@nokia.com
> > > Sent: Thursday, December 13, 2007 5:08 PM
> > > To: client-dev@helixcommunity.org;
> filesystem-dev@helixcommunity.org
> > > Subject: [Client-dev] How do we find out the mime type when URL
> > > doesn'tcontain file extension?
> > >
> > > I am trying to get shout cast links(most of them don't have file
> > > extension as a part of url eg:
> > > http://195.214.242.74:8000 )
> > working on
> > > helix.
> > >
> > > In httpfilesys, once we get 200 OK then content-type and
> mime type
> > > pair values are set by the httpfilesys on the response
> > header. Hence
> > > Hxfilesource can use these values to know the mime type
> > during extend
> > > setup.
> > >
> > > HxFileSource instantiates httpfilesys during setup and
> while doing
> > > extended Setup, it looks for content type and mime type
> value pair
> > > provided by the httpfilesys. If these values are existing,
> > then Url is
> >
> > > taken care without looking for file extension.
> > >
> > > But in httpfilesys we get 200 OK only during finish Setup.
> > > Hence httpfilesys can provided these content type and mime
> > type value
> > > only after filesource done with extended setup.
> > >
> > > how exactly are we handling this case?
> > >
> > > Thanks
> > > Praveen
> > >
> > >
> >
>
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.