Re: [swift-corelibs-dev] Implementing HTTPCookieStorage

[Itai Ferber via swift-corelibs-dev]

>From my (potentially limited) experience, I would say that yes, many tools out 
>there do follow this spec.
I only have anecdotal evidence to back this up, but I think many new tools use 
this convention, and those that don't do not out of long-standing conventions 
that say otherwise (e.g. `~/.vimrc`, `~/.emacs.d`, etc.). Someone with more 
immediate access to a Linux box can maybe help back this up.

I personally like this convention, and think it's a safe option. We are highly 
unlikely to conflict with anything in `~/.config` or `~/.local`.

On 14 Nov 2016, at 11:37, Tony Parker via swift-corelibs-dev wrote:

>
>> On Nov 14, 2016, at 10:47 AM, Will Stanton  wrote:
>>
>> Hello Tony and Philippe,
>>
>> I don’t think it would be odd for cookie/setting files to be in a folder 
>> named after Foundation (namely ~/.foundation):
>> - The files are owned by Swift/Linux Foundation in the sense Foundation 
>> writes them, and Foundation is the only one that should access them 
>> directly. Foundation should enforce security.
>> - On macOS, settings seem to be written to 
>> ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed 
>> ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different.
>> ‘.foundation’ is used in lieu of a library directory, and I feel this is 
>> acceptable so as not to clash with any user ~/Preferences or ~/Library 
>> directory.  I am OK with the ‘Foundation ownership’ per above.
>> And, executable name seems reasonable in lieu of bundle ID.
>>
>> I noted something like 
>> ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to 
>> keep symmetry/reuse more CF code, but changing Swift CF is probably 
>> necessary anyway and better (fewer search paths to loop through, possibly 
>> less I/O).
>>
>
> Agreed, I don’t have any problem with baking a set of rules into CF that is 
> specific to various platforms. That’s it’s job after all.
>
>>
>> Am interested in alternatives of course :-)
>> - But having separate folders for each app seems complicated, ex. 
>> '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home.
>> - I don’t really mind the name of an encapsulating folder, .foundation or 
>> otherwise.
>> - Placing system configuration files in /etc is a norm, but I think I’d feel 
>> more comfortable with Swift app settings in /home/user (easier to keep track 
>> of, and I can delete the whole thing without consequences*). I’m also not 
>> writing any real low-level services in Swift… but others probably are… but 
>> they probably have their own code to write config data to /etc!
>>
>
> Off-list, someone pointed me here:
>
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> and here:
>
> http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix
>
> Noting that there seems to be a growing consensus for $HOME/.config.
>
> Is this spec beginning to be used in the real world?
>
> - Tony
>
>>
>> To Philippe’s points about security+future-proofing:
>> Perhaps the cookie file could be named per version of its format:
>> ~/.foundation/Cookies/shared initially
>> When we have a new format:
>> ~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name 
>> entirely?
>>
>> I also think it should be up to Swift Foundation to enforce cookie security 
>> on a per-app/family basis (the latter requires changes to the package 
>> structure?).
>> Perhaps for now, it is possible to save the hash and name of the executable 
>> storing a cookie? And Foundation can load cookie storage only if the 
>> executable name and file haven’t changed? (Is that an unnecessary pain?)
>>
>> Regards,
>> Will Stanton
>>
>>> On Nov 14, 2016, at 12:44 PM, Tony Parker  wrote:
>>>
>>> Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when 
>>> Foundation is just one of the libraries involved? On Darwin, the prefs are 
>>> organized by application, not by framework.
>>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


signature.asc
Description: OpenPGP digital signature
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Adding type conversion capabilities to JSON encode/decode

[Itai Ferber via swift-corelibs-dev]

Hi Brandon,

Thanks for looking at this! We’ve got plans internally to potentially 
add a strategy to `JSONEncoder`/`JSONDecoder` to allow lenient 
conversions like this — i.e. implicitly stringify numbers (or parse 
them from string input), among some others.
This would be opt-in for consumers of `JSONDecoder` while not requiring 
any special annotations on `Codable` types.


— Itai

On 30 Aug 2017, at 10:59, Sneed, Brandon via swift-corelibs-dev wrote:


Hi everyone,

Just throwing this out to see if anyone else is working on this, or 
has opinions/suggestions on how it’s implemented.  I’d like to add 
this to the Codable/JSONDecoder/JSONEncoder system if no one else is 
working on it.


Type type conversion, I mean given this JSON payload:

{
"name": "Endeavor”,
"abv": 8.9,
"brewery": "Saint Arnold”,
"style": "ipa"
}

and a struct defined as:

struct Beer: Codable {
let name: String
let abv: String
let brewery: String
let style: BeerStyle
}

Notice that “abv” is a number in the JSON, but a String in the 
struct.  I’d like to make it such that I can let the system know 
it’s ok to convert it from a number to a string as opposed to 
throwing an exception.  The benefits are:


1.   It’s defensive; service types can change without causing my 
application to crash.
2.   It allows a developer to work with the types they want to 
work with as opposed to what the server provides, thus saving them 
time of writing a custom encode/decode code for all members.


The argument against it that I’ve heard is generally “it’s a 
service bug, make them fix it”, which is valid but the reality is 
we’re not all in control of the services we injest.  The same type 
of logic could be applied to a member name changing, though I 
haven’t seen this happen often in practice.  I do see types in a 
json payload change with some frequency though.  I think much of the 
reason stems from the fact that type conversion in javascript is 
effectively free, ie: you ask for a String, you get a String if 
possible.


To implement this type conversion in practice, looking at it from the 
point of view using Codable/JSON(en/de)coder, one way would be to make 
it opt-in:


struct Beer: Codable, CodingConvertible {
let name: String
let abv: String
let brewery: String
let style: BeerStyle
}

I like this because looking at the struct, the members still remain 
clear and relatively unambiguous.  The downside is it’s unknown 
which member is likely to get converted.  And since it’s opt-in, 
conversion doesn’t happen if the CodingConvertible conformance 
isn’t adhered to.


Another option would be to box each type, like so:

struct Beer: Codable {
let name: String
let abv: Convertible
let brewery: String
let style: BeerStyle
}

This seems tedious for developers, but would show which types are 
being converted.  It does however seriously weaken benefit #1 above.


Those example usages above aside, I do think it’d be best if this 
conversion behavior was the default and no end-developer changes 
required.  I think that could be done without impact to code that’s 
been already been written against the JSON en/decode bits.


I’m very open to alternatives, other ideas, or anything else you 
might have to say on the subject.  Thanks for reading!




Brandon Sneed




___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] encodeEncodable/decodeDecodable

[Itai Ferber via swift-corelibs-dev]

Hi Luke,

Thanks for putting this together! Do you mind putting that up as a [pull 
request](https://github.com/apple/swift-corelibs-foundation/pulls) so we 
can review it more formally and run it through CI?


— Itai

On 22 Sep 2017, at 19:53, Luke Howard via swift-corelibs-dev wrote:


Had a crack on this, is anyone able to test this on Linux?

https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e 



On 20 Sep 2017, at 23:30, Luke Howard via swift-corelibs-dev 
 wrote:


I’m fairly out of touch with Swift these days, but I took a quick 
look at importing the encodeEncodable/decodeDecodable changes from 
stdlib into SwiftFoundation.


I ran into a bunch of bridging issues with the PropertyListDecoder, 
where it would be balk on the encoded property list types being 
Foundation instead of Swift types (e.g. “Expected to decode 
Dictionary but found a dictionary instead”).


Not sure the best way to workaround these: I started doing so 
explicitly in the unbox methods, but it didn’t feel intuitively 
right (apart from all the boilerplate code, sometimes the input value 
would be a Foundation object, other times not). I haven’t had time 
to investigate further.


Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 
___

swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 





___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] encodeEncodable/decodeDecodable

[Itai Ferber via swift-corelibs-dev]

Hi Luke,

Thanks for putting this together! In the meantime, CI testing has 
highlighted an issue that will need to be solved before this can be 
pulled in — namely that `NSKeyedUnarchiver` is currently incomplete as 
it does not implement or override `failWithError` properly.

This is something we’ll need to do in order to support this properly.

— Itai

On 27 Sep 2017, at 7:35, Luke Howard wrote:

Still having trouble building it on Linux – I did kind of get it 
built from swift-4.0-branch, but didn’t have a working lldb so was 
difficult to debug (except by printf). Currently appear to be running 
into SR-5938 when trying to build from master.


On 26 Sep 2017, at 09:37, Luke Howard via swift-corelibs-dev 
 wrote:


Hi Itai,

Pull request is here 
, 
unfortunately tests are failing on Linux. I’m still trying to get 
Swift built on Linux so I can investigate (didn’t have any luck 
using the prebuilt binaries to build Foundation).


Cheers,
Luke

On 26 Sep 2017, at 06:24, Itai Ferber > wrote:


Hi Luke,

Thanks for putting this together! Do you mind putting that up as a 
pull request 
 so we can 
review it more formally and run it through CI?


— Itai

On 22 Sep 2017, at 19:53, Luke Howard via swift-corelibs-dev wrote:

Had a crack on this, is anyone able to test this on Linux?

https://github.com/lhoward/swift-corelibs-foundation/commit/8f8d16c8d68f1af7730522e728d96f8d93c88a2e 



On 20 Sep 2017, at 23:30, Luke Howard via swift-corelibs-dev 
> wrote:


I’m fairly out of touch with Swift these days, but I took a quick 
look at importing the encodeEncodable/decodeDecodable changes from 
stdlib into SwiftFoundation.


I ran into a bunch of bridging issues with the PropertyListDecoder, 
where it would be balk on the encoded property list types being 
Foundation instead of Swift types (e.g. “Expected to decode 
Dictionary but found a dictionary instead”).


Not sure the best way to workaround these: I started doing so 
explicitly in the unbox methods, but it didn’t feel intuitively 
right (apart from all the boilerplate code, sometimes the input 
value would be a Foundation object, other times not). I haven’t 
had time to investigate further.


Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 
___

swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org 
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 



Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 


___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org 
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 



Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 


___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 




___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] JSONDecoder has too few opportunities. need an enhancement.

[Itai Ferber via swift-corelibs-dev]

Hi Vladimir,

> On Nov 9, 2017, at 8:36 AM, Vladimir Kushelkov via swift-corelibs-dev 
>  wrote:
> 
> 1. Sometimes it is contently to be able to decode a struct or an object from 
> a Foundation object (either NSArray or NSDictionary) that produce a valid 
> JSON.
> For example, if I use a 3d party library that provides NSDictionary to me. 
> Due to JSONDecoder decodes only from Data, in the first place I have to 
> convert NSDictionary to Data in order to use the one so far. But the decoder 
> does the back action first thing.
> I created Pull Request , that was 
> closed.
Thanks for putting together this pull request! As Tony mentioned in his 
response to it, this type of change would need to go through API review, both 
internal, and external, before we could accept it.
This needs to be squared away with other work on 
JSONDecoder/PropertyListDecoder — you may have seen a recent email on here from 
Florent Vilmart about exposing the underlying _JSONEncoder and _JSONDecoder; 
we’re currently considering exposing the underlying conversion mechanism here 
in an Encoder/Decoder pair similar to Norio’s ObjectEncoder. There might be a 
more general solution here than just exposing the behavior on JSONDecoder.

This is being tracked internally, and I hope to have a good answer in the next 
Swift release. In the meantime, there are workarounds like what Norio has done.

> 2. Is it possible to use JSONDecoder when I don’t know the type of a 
> particular property of the required type?
> For instance, if I develop a library that allows bi-directional communication 
> between server and client. The library wraps transmitted data into an 
> internal object in a way that one of the object’s properties is the data. So, 
> the type of the property is unknown inside the library. I want to decode the 
> internal object with JSONDecoder, but I can’t specify the type of one 
> property.
No, this is not possible. You cannot decode an object without being able to 
specify its type statically — you’ll need the client to somehow pass along the 
type, or provide enough information for you to decode on their behalf.

> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev