NME patch for review

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

NME patch for review

Joshua Harlan Lifton
This patch for NME r712 contains the following changes:

Added nme.Lib.getResourcePath (returns null except for on iOS).

Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).

Better handling of HTTP status codes (raises an error for codes >= 400).

Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
file and tells libcurl to use SSL - this alone won't enable HTTPS, but
it's one step on the way to doing so).

Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.

Cheers,
Josh

--
haXe - an open source web programming language
http://haxe.org

nme_patch_r712.txt (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

singmajesty
These seem to be good improvements. Do you think we could put them  
elsewhere in the API?

For example, we could use  
"nme.filesystem.File.applicationStorageDirectory" instead of  
"nme.Lib.getResourcePath" to mirror the Adobe AIR API. There is no way to  
get a unique identifier in AIR, but "nme.system.System.hardwareID" might  
be a good place to put it.

Is it still possible to use URLLoader without calling  
URLLoader.initialize(), after your patch? It would be great to be able to  
use it like normal if you do not need to use SSL.



On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton  
<[hidden email]> wrote:

> This patch for NME r712 contains the following changes:
>
> Added nme.Lib.getResourcePath (returns null except for on iOS).
>
> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).
>
> Better handling of HTTP status codes (raises an error for codes >= 400).
>
> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
> it's one step on the way to doing so).
>
> Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.
>
> Cheers,
> Josh


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Joshua Harlan Lifton
I'll move getResourcePath and getUniqueDeviceIdentifier as you
suggested. URLLoader can still be used as usual, without calling
URLLoader.initialize. At this point, even calling URLLoader.initialize
won't have an effect unless you've put the SSL-enabled libraries in
the right places.

Thanks,
Josh

On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
<[hidden email]> wrote:

> These seem to be good improvements. Do you think we could put them elsewhere
> in the API?
>
> For example, we could use "nme.filesystem.File.applicationStorageDirectory"
> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API. There is
> no way to get a unique identifier in AIR, but "nme.system.System.hardwareID"
> might be a good place to put it.
>
> Is it still possible to use URLLoader without calling
> URLLoader.initialize(), after your patch? It would be great to be able to
> use it like normal if you do not need to use SSL.
>
>
>
> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
> <[hidden email]> wrote:
>
>> This patch for NME r712 contains the following changes:
>>
>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>
>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).
>>
>> Better handling of HTTP status codes (raises an error for codes >= 400).
>>
>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>> it's one step on the way to doing so).
>>
>> Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.
>>
>> Cheers,
>> Josh
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Joshua Harlan Lifton
Attached is the revised patch. I went with
nme.filesystem.File.applicationStorageDirectory (though it's a String,
not a File and the remainder of File is unimplemented), and
nme.system.System.deviceId.

Cheers,
Josh

On Sun, Jul 3, 2011 at 11:21 PM, Joshua Harlan Lifton
<[hidden email]> wrote:

> I'll move getResourcePath and getUniqueDeviceIdentifier as you
> suggested. URLLoader can still be used as usual, without calling
> URLLoader.initialize. At this point, even calling URLLoader.initialize
> won't have an effect unless you've put the SSL-enabled libraries in
> the right places.
>
> Thanks,
> Josh
>
> On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
> <[hidden email]> wrote:
>> These seem to be good improvements. Do you think we could put them elsewhere
>> in the API?
>>
>> For example, we could use "nme.filesystem.File.applicationStorageDirectory"
>> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API. There is
>> no way to get a unique identifier in AIR, but "nme.system.System.hardwareID"
>> might be a good place to put it.
>>
>> Is it still possible to use URLLoader without calling
>> URLLoader.initialize(), after your patch? It would be great to be able to
>> use it like normal if you do not need to use SSL.
>>
>>
>>
>> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>
>>> This patch for NME r712 contains the following changes:
>>>
>>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>>
>>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).
>>>
>>> Better handling of HTTP status codes (raises an error for codes >= 400).
>>>
>>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>>> it's one step on the way to doing so).
>>>
>>> Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.
>>>
>>> Cheers,
>>> Josh
>>
>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>
>

--
haXe - an open source web programming language
http://haxe.org

nme_patch_r712_1.txt (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

singmajesty
That makes sense... on webOS, the C call is "GetHardwareID", but I can see  
that Android uses "getDeviceId" and iOS uses "uniqueIdentifier"

Would you mind if we capitalized the 'd', so "nme.system.System.deviceID"?



On Sun, 03 Jul 2011 21:28:06 -0700, Joshua Harlan Lifton  
<[hidden email]> wrote:

> Attached is the revised patch. I went with
> nme.filesystem.File.applicationStorageDirectory (though it's a String,
> not a File and the remainder of File is unimplemented), and
> nme.system.System.deviceId.
>
> Cheers,
> Josh
>
> On Sun, Jul 3, 2011 at 11:21 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> I'll move getResourcePath and getUniqueDeviceIdentifier as you
>> suggested. URLLoader can still be used as usual, without calling
>> URLLoader.initialize. At this point, even calling URLLoader.initialize
>> won't have an effect unless you've put the SSL-enabled libraries in
>> the right places.
>>
>> Thanks,
>> Josh
>>
>> On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
>> <[hidden email]> wrote:
>>> These seem to be good improvements. Do you think we could put them  
>>> elsewhere
>>> in the API?
>>>
>>> For example, we could use  
>>> "nme.filesystem.File.applicationStorageDirectory"
>>> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API.  
>>> There is
>>> no way to get a unique identifier in AIR, but  
>>> "nme.system.System.hardwareID"
>>> might be a good place to put it.
>>>
>>> Is it still possible to use URLLoader without calling
>>> URLLoader.initialize(), after your patch? It would be great to be able  
>>> to
>>> use it like normal if you do not need to use SSL.
>>>
>>>
>>>
>>> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
>>> <[hidden email]> wrote:
>>>
>>>> This patch for NME r712 contains the following changes:
>>>>
>>>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>>>
>>>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on  
>>>> iOS).
>>>>
>>>> Better handling of HTTP status codes (raises an error for codes >=  
>>>> 400).
>>>>
>>>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>>>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>>>> it's one step on the way to doing so).
>>>>
>>>> Code reviews are welcome. If I don't hear anything, I'll commit  
>>>> tomorrow.
>>>>
>>>> Cheers,
>>>> Josh
>>>
>>>
>>> --
>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>
>>


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Alex Liebert
In reply to this post by Joshua Harlan Lifton
Maybe we should implement File with just the .url and .nativePath
properties, plus the static applicationDirectory/documentsDirectory
etc accessors.

This way, when porting to/from flash it will work as is for the
supported features (instead of returning string directly.)

Alex

On Sun, Jul 3, 2011 at 9:28 PM, Joshua Harlan Lifton
<[hidden email]> wrote:

> Attached is the revised patch. I went with
> nme.filesystem.File.applicationStorageDirectory (though it's a String,
> not a File and the remainder of File is unimplemented), and
> nme.system.System.deviceId.
>
> Cheers,
> Josh
>
> On Sun, Jul 3, 2011 at 11:21 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> I'll move getResourcePath and getUniqueDeviceIdentifier as you
>> suggested. URLLoader can still be used as usual, without calling
>> URLLoader.initialize. At this point, even calling URLLoader.initialize
>> won't have an effect unless you've put the SSL-enabled libraries in
>> the right places.
>>
>> Thanks,
>> Josh
>>
>> On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
>> <[hidden email]> wrote:
>>> These seem to be good improvements. Do you think we could put them elsewhere
>>> in the API?
>>>
>>> For example, we could use "nme.filesystem.File.applicationStorageDirectory"
>>> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API. There is
>>> no way to get a unique identifier in AIR, but "nme.system.System.hardwareID"
>>> might be a good place to put it.
>>>
>>> Is it still possible to use URLLoader without calling
>>> URLLoader.initialize(), after your patch? It would be great to be able to
>>> use it like normal if you do not need to use SSL.
>>>
>>>
>>>
>>> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
>>> <[hidden email]> wrote:
>>>
>>>> This patch for NME r712 contains the following changes:
>>>>
>>>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>>>
>>>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).
>>>>
>>>> Better handling of HTTP status codes (raises an error for codes >= 400).
>>>>
>>>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>>>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>>>> it's one step on the way to doing so).
>>>>
>>>> Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.
>>>>
>>>> Cheers,
>>>> Josh
>>>
>>>
>>> --
>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Joshua Harlan Lifton
In reply to this post by singmajesty
I was hoping to start a heated debate about deviceId versus deviceID,
but I see that precedent in the NME code base clearly favors deviceID.
I'll make the change accordingly.

On Mon, Jul 4, 2011 at 1:00 PM, Joshua Granick
<[hidden email]> wrote:

> That makes sense... on webOS, the C call is "GetHardwareID", but I can see
> that Android uses "getDeviceId" and iOS uses "uniqueIdentifier"
>
> Would you mind if we capitalized the 'd', so "nme.system.System.deviceID"?
>
>
>
> On Sun, 03 Jul 2011 21:28:06 -0700, Joshua Harlan Lifton
> <[hidden email]> wrote:
>
>> Attached is the revised patch. I went with
>> nme.filesystem.File.applicationStorageDirectory (though it's a String,
>> not a File and the remainder of File is unimplemented), and
>> nme.system.System.deviceId.
>>
>> Cheers,
>> Josh
>>
>> On Sun, Jul 3, 2011 at 11:21 PM, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>>
>>> I'll move getResourcePath and getUniqueDeviceIdentifier as you
>>> suggested. URLLoader can still be used as usual, without calling
>>> URLLoader.initialize. At this point, even calling URLLoader.initialize
>>> won't have an effect unless you've put the SSL-enabled libraries in
>>> the right places.
>>>
>>> Thanks,
>>> Josh
>>>
>>> On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
>>> <[hidden email]> wrote:
>>>>
>>>> These seem to be good improvements. Do you think we could put them
>>>> elsewhere
>>>> in the API?
>>>>
>>>> For example, we could use
>>>> "nme.filesystem.File.applicationStorageDirectory"
>>>> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API. There
>>>> is
>>>> no way to get a unique identifier in AIR, but
>>>> "nme.system.System.hardwareID"
>>>> might be a good place to put it.
>>>>
>>>> Is it still possible to use URLLoader without calling
>>>> URLLoader.initialize(), after your patch? It would be great to be able
>>>> to
>>>> use it like normal if you do not need to use SSL.
>>>>
>>>>
>>>>
>>>> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
>>>> <[hidden email]> wrote:
>>>>
>>>>> This patch for NME r712 contains the following changes:
>>>>>
>>>>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>>>>
>>>>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on
>>>>> iOS).
>>>>>
>>>>> Better handling of HTTP status codes (raises an error for codes >=
>>>>> 400).
>>>>>
>>>>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>>>>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>>>>> it's one step on the way to doing so).
>>>>>
>>>>> Code reviews are welcome. If I don't hear anything, I'll commit
>>>>> tomorrow.
>>>>>
>>>>> Cheers,
>>>>> Josh
>>>>
>>>>
>>>> --
>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>>
>>>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Joshua Harlan Lifton
In reply to this post by Alex Liebert
Yes, I agree - a minimal API-compliant File class is a better
solution. I'll post another patch after I make those changes.

Thanks,
Josh

On Mon, Jul 4, 2011 at 1:49 PM, Alex Liebert <[hidden email]> wrote:

> Maybe we should implement File with just the .url and .nativePath
> properties, plus the static applicationDirectory/documentsDirectory
> etc accessors.
>
> This way, when porting to/from flash it will work as is for the
> supported features (instead of returning string directly.)
>
> Alex
>
> On Sun, Jul 3, 2011 at 9:28 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> Attached is the revised patch. I went with
>> nme.filesystem.File.applicationStorageDirectory (though it's a String,
>> not a File and the remainder of File is unimplemented), and
>> nme.system.System.deviceId.
>>
>> Cheers,
>> Josh
>>
>> On Sun, Jul 3, 2011 at 11:21 PM, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>> I'll move getResourcePath and getUniqueDeviceIdentifier as you
>>> suggested. URLLoader can still be used as usual, without calling
>>> URLLoader.initialize. At this point, even calling URLLoader.initialize
>>> won't have an effect unless you've put the SSL-enabled libraries in
>>> the right places.
>>>
>>> Thanks,
>>> Josh
>>>
>>> On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
>>> <[hidden email]> wrote:
>>>> These seem to be good improvements. Do you think we could put them elsewhere
>>>> in the API?
>>>>
>>>> For example, we could use "nme.filesystem.File.applicationStorageDirectory"
>>>> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API. There is
>>>> no way to get a unique identifier in AIR, but "nme.system.System.hardwareID"
>>>> might be a good place to put it.
>>>>
>>>> Is it still possible to use URLLoader without calling
>>>> URLLoader.initialize(), after your patch? It would be great to be able to
>>>> use it like normal if you do not need to use SSL.
>>>>
>>>>
>>>>
>>>> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
>>>> <[hidden email]> wrote:
>>>>
>>>>> This patch for NME r712 contains the following changes:
>>>>>
>>>>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>>>>
>>>>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).
>>>>>
>>>>> Better handling of HTTP status codes (raises an error for codes >= 400).
>>>>>
>>>>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>>>>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>>>>> it's one step on the way to doing so).
>>>>>
>>>>> Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.
>>>>>
>>>>> Cheers,
>>>>> Josh
>>>>
>>>>
>>>> --
>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>>
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Tarwin Stroh-Spijer
I double checked the AS3 / Flex code conventions (http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions) and under "Word boundaries" they talk about acronym-casing. It seems they always use UPPERCASE for acronyms. Personally I don't like it, but it's best to keep with what we've got!


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Tue, Jul 5, 2011 at 12:04 PM, Joshua Harlan Lifton <[hidden email]> wrote:
Yes, I agree - a minimal API-compliant File class is a better
solution. I'll post another patch after I make those changes.

Thanks,
Josh

On Mon, Jul 4, 2011 at 1:49 PM, Alex Liebert <[hidden email]> wrote:
> Maybe we should implement File with just the .url and .nativePath
> properties, plus the static applicationDirectory/documentsDirectory
> etc accessors.
>
> This way, when porting to/from flash it will work as is for the
> supported features (instead of returning string directly.)
>
> Alex
>
> On Sun, Jul 3, 2011 at 9:28 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> Attached is the revised patch. I went with
>> nme.filesystem.File.applicationStorageDirectory (though it's a String,
>> not a File and the remainder of File is unimplemented), and
>> nme.system.System.deviceId.
>>
>> Cheers,
>> Josh
>>
>> On Sun, Jul 3, 2011 at 11:21 PM, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>> I'll move getResourcePath and getUniqueDeviceIdentifier as you
>>> suggested. URLLoader can still be used as usual, without calling
>>> URLLoader.initialize. At this point, even calling URLLoader.initialize
>>> won't have an effect unless you've put the SSL-enabled libraries in
>>> the right places.
>>>
>>> Thanks,
>>> Josh
>>>
>>> On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
>>> <[hidden email]> wrote:
>>>> These seem to be good improvements. Do you think we could put them elsewhere
>>>> in the API?
>>>>
>>>> For example, we could use "nme.filesystem.File.applicationStorageDirectory"
>>>> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API. There is
>>>> no way to get a unique identifier in AIR, but "nme.system.System.hardwareID"
>>>> might be a good place to put it.
>>>>
>>>> Is it still possible to use URLLoader without calling
>>>> URLLoader.initialize(), after your patch? It would be great to be able to
>>>> use it like normal if you do not need to use SSL.
>>>>
>>>>
>>>>
>>>> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
>>>> <[hidden email]> wrote:
>>>>
>>>>> This patch for NME r712 contains the following changes:
>>>>>
>>>>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>>>>
>>>>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).
>>>>>
>>>>> Better handling of HTTP status codes (raises an error for codes >= 400).
>>>>>
>>>>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>>>>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>>>>> it's one step on the way to doing so).
>>>>>
>>>>> Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.
>>>>>
>>>>> Cheers,
>>>>> Josh
>>>>
>>>>
>>>> --
>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>>
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Tony Polinelli
is ID really an acronym tho? ... what does it say about abbreviations ? ;P



On Tue, Jul 5, 2011 at 12:31 PM, Tarwin Stroh-Spijer <[hidden email]> wrote:
I double checked the AS3 / Flex code conventions (http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions) and under "Word boundaries" they talk about acronym-casing. It seems they always use UPPERCASE for acronyms. Personally I don't like it, but it's best to keep with what we've got!


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
_______________________



On Tue, Jul 5, 2011 at 12:04 PM, Joshua Harlan Lifton <[hidden email]> wrote:
Yes, I agree - a minimal API-compliant File class is a better
solution. I'll post another patch after I make those changes.

Thanks,
Josh

On Mon, Jul 4, 2011 at 1:49 PM, Alex Liebert <[hidden email]> wrote:
> Maybe we should implement File with just the .url and .nativePath
> properties, plus the static applicationDirectory/documentsDirectory
> etc accessors.
>
> This way, when porting to/from flash it will work as is for the
> supported features (instead of returning string directly.)
>
> Alex
>
> On Sun, Jul 3, 2011 at 9:28 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> Attached is the revised patch. I went with
>> nme.filesystem.File.applicationStorageDirectory (though it's a String,
>> not a File and the remainder of File is unimplemented), and
>> nme.system.System.deviceId.
>>
>> Cheers,
>> Josh
>>
>> On Sun, Jul 3, 2011 at 11:21 PM, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>> I'll move getResourcePath and getUniqueDeviceIdentifier as you
>>> suggested. URLLoader can still be used as usual, without calling
>>> URLLoader.initialize. At this point, even calling URLLoader.initialize
>>> won't have an effect unless you've put the SSL-enabled libraries in
>>> the right places.
>>>
>>> Thanks,
>>> Josh
>>>
>>> On Sun, Jul 3, 2011 at 9:01 PM, Joshua Granick
>>> <[hidden email]> wrote:
>>>> These seem to be good improvements. Do you think we could put them elsewhere
>>>> in the API?
>>>>
>>>> For example, we could use "nme.filesystem.File.applicationStorageDirectory"
>>>> instead of "nme.Lib.getResourcePath" to mirror the Adobe AIR API. There is
>>>> no way to get a unique identifier in AIR, but "nme.system.System.hardwareID"
>>>> might be a good place to put it.
>>>>
>>>> Is it still possible to use URLLoader without calling
>>>> URLLoader.initialize(), after your patch? It would be great to be able to
>>>> use it like normal if you do not need to use SSL.
>>>>
>>>>
>>>>
>>>> On Sun, 03 Jul 2011 16:18:33 -0700, Joshua Harlan Lifton
>>>> <[hidden email]> wrote:
>>>>
>>>>> This patch for NME r712 contains the following changes:
>>>>>
>>>>> Added nme.Lib.getResourcePath (returns null except for on iOS).
>>>>>
>>>>> Added nme.Lib.getUniqueDeviceIdentifier (returns null except for on iOS).
>>>>>
>>>>> Better handling of HTTP status codes (raises an error for codes >= 400).
>>>>>
>>>>> Groundwork for using HTTPS (URLLoader.initialize takes in a CA certs
>>>>> file and tells libcurl to use SSL - this alone won't enable HTTPS, but
>>>>> it's one step on the way to doing so).
>>>>>
>>>>> Code reviews are welcome. If I don't hear anything, I'll commit tomorrow.
>>>>>
>>>>> Cheers,
>>>>> Josh
>>>>
>>>>
>>>> --
>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>>
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Joshua Harlan Lifton
In reply to this post by Joshua Harlan Lifton
Attached is a revised patch to reflect the changes discussed in this
thread (deviceId to deviceID and applicationDirectory being a File
object rather than a String). The implementation of
nme.filesystem.File is very thin and neither the url setter nor the
nativePath setter is as complete as it should be, but it's a start.
I'll commit tomorrow unless I hear otherwise. Alex, will patch
interfere with the larger SharedObject patch you're preparing?

Cheers,
Josh

--
haXe - an open source web programming language
http://haxe.org

nme_patch_r714.txt (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Alex Liebert
Hi Josh,

Commit when ready- I'll just merge later.  I seem to have gotten
myself in a state where I can't build anything at all so I'm taking a
break til tomorrow to try anew.  Have you been able to build for
Android recently?

Alex

On Wed, Jul 6, 2011 at 8:39 PM, Joshua Harlan Lifton
<[hidden email]> wrote:

> Attached is a revised patch to reflect the changes discussed in this
> thread (deviceId to deviceID and applicationDirectory being a File
> object rather than a String). The implementation of
> nme.filesystem.File is very thin and neither the url setter nor the
> nativePath setter is as complete as it should be, but it's a start.
> I'll commit tomorrow unless I hear otherwise. Alex, will patch
> interfere with the larger SharedObject patch you're preparing?
>
> Cheers,
> Josh
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Joshua Harlan Lifton
Revision 717 has my changes. I haven't tried targeting Android, though
I did notice that my project isn't building under Xcode 4.0.2 even
though it builds on 4.0.1. Not sure if the problem is with Xcode or
something else I forgot to set up. It's always good to have company,
right?

Josh

On Thu, Jul 7, 2011 at 1:08 AM, Alex Liebert <[hidden email]> wrote:

> Hi Josh,
>
> Commit when ready- I'll just merge later.  I seem to have gotten
> myself in a state where I can't build anything at all so I'm taking a
> break til tomorrow to try anew.  Have you been able to build for
> Android recently?
>
> Alex
>
> On Wed, Jul 6, 2011 at 8:39 PM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> Attached is a revised patch to reflect the changes discussed in this
>> thread (deviceId to deviceID and applicationDirectory being a File
>> object rather than a String). The implementation of
>> nme.filesystem.File is very thin and neither the url setter nor the
>> nativePath setter is as complete as it should be, but it's a start.
>> I'll commit tomorrow unless I hear otherwise. Alex, will patch
>> interfere with the larger SharedObject patch you're preparing?
>>
>> Cheers,
>> Josh
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Alex Liebert
Indeed :)  I gave up on xcode 4 and went back to 3 without any issues
(other than sitting through another ridiculous 6 GB download session.)
 Though I think I did that because the old xcode templates from the
2.0.1 stable version of nme didn't work in xcode 4, so haven't tried
the install-tool route with it.

On Thu, Jul 7, 2011 at 10:00 AM, Joshua Harlan Lifton
<[hidden email]> wrote:

> Revision 717 has my changes. I haven't tried targeting Android, though
> I did notice that my project isn't building under Xcode 4.0.2 even
> though it builds on 4.0.1. Not sure if the problem is with Xcode or
> something else I forgot to set up. It's always good to have company,
> right?
>
> Josh
>
> On Thu, Jul 7, 2011 at 1:08 AM, Alex Liebert <[hidden email]> wrote:
>> Hi Josh,
>>
>> Commit when ready- I'll just merge later.  I seem to have gotten
>> myself in a state where I can't build anything at all so I'm taking a
>> break til tomorrow to try anew.  Have you been able to build for
>> Android recently?
>>
>> Alex
>>
>> On Wed, Jul 6, 2011 at 8:39 PM, Joshua Harlan Lifton
>> <[hidden email]> wrote:
>>> Attached is a revised patch to reflect the changes discussed in this
>>> thread (deviceId to deviceID and applicationDirectory being a File
>>> object rather than a String). The implementation of
>>> nme.filesystem.File is very thin and neither the url setter nor the
>>> nativePath setter is as complete as it should be, but it's a start.
>>> I'll commit tomorrow unless I hear otherwise. Alex, will patch
>>> interfere with the larger SharedObject patch you're preparing?
>>>
>>> Cheers,
>>> Josh
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME patch for review

Joshua Harlan Lifton
I highly recommend install-tool. It's gotten a lot better for iOS in
the last month or so.

Josh

On Thu, Jul 7, 2011 at 2:19 PM, Alex Liebert <[hidden email]> wrote:

> Indeed :)  I gave up on xcode 4 and went back to 3 without any issues
> (other than sitting through another ridiculous 6 GB download session.)
>  Though I think I did that because the old xcode templates from the
> 2.0.1 stable version of nme didn't work in xcode 4, so haven't tried
> the install-tool route with it.
>
> On Thu, Jul 7, 2011 at 10:00 AM, Joshua Harlan Lifton
> <[hidden email]> wrote:
>> Revision 717 has my changes. I haven't tried targeting Android, though
>> I did notice that my project isn't building under Xcode 4.0.2 even
>> though it builds on 4.0.1. Not sure if the problem is with Xcode or
>> something else I forgot to set up. It's always good to have company,
>> right?
>>
>> Josh
>>
>> On Thu, Jul 7, 2011 at 1:08 AM, Alex Liebert <[hidden email]> wrote:
>>> Hi Josh,
>>>
>>> Commit when ready- I'll just merge later.  I seem to have gotten
>>> myself in a state where I can't build anything at all so I'm taking a
>>> break til tomorrow to try anew.  Have you been able to build for
>>> Android recently?
>>>
>>> Alex
>>>
>>> On Wed, Jul 6, 2011 at 8:39 PM, Joshua Harlan Lifton
>>> <[hidden email]> wrote:
>>>> Attached is a revised patch to reflect the changes discussed in this
>>>> thread (deviceId to deviceID and applicationDirectory being a File
>>>> object rather than a String). The implementation of
>>>> nme.filesystem.File is very thin and neither the url setter nor the
>>>> nativePath setter is as complete as it should be, but it's a start.
>>>> I'll commit tomorrow unless I hear otherwise. Alex, will patch
>>>> interfere with the larger SharedObject patch you're preparing?
>>>>
>>>> Cheers,
>>>> Josh
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org