probablycorey / seriously Goto Github PK

I've been maintaining my own fork of seriously for a little over 2 years. Recently, when the project needed a new maintainer I was happy to step in. That said I'd like to see if there is any community feedback on my fork and possibly merge it into master in the future.

The major difference between my fork and the original is that I removed the JSON parser from seriously and left the project to focus on making http requests with blocks for callbacks. The JSON parser code is still in my fork, but it gets built as a separate static library.

I have also added a small iPhone project to my fork with a live demo of using seriously.

I have paid attention to the original fork and have seen some new features that have gone in that I do not currently have in my fork. I plan to merge those into my fork, and if there is no major opposition to splitting the JSON parser out of the core of seriously, eventually merge my fork into probablycorey/master.

I've pushed a copy of my fork to https://github.com/probablycorey/seriously/tree/a-new-direction so that people can have a chance to look at/comment on it. I plan to leave this issue open for a bit to see if there are any objections and then get started with merging things.

Hello, I am experiencing an exception that is being raised in the SeriouslyJSON class, at line 167, in the parse: method:

[NSException raise:@"Seriously Error" format:@"Problem parsing JSON data %s", error];

This is crashing my app. Now what the server is actually returning is a status code of 406, and a response body of content-length 1, that has a junk character in it, as there was an error condition.

In tracing through the Seriously code, I'm not finding where Seriously is checking the status code of the HTTP response before deciding whether to parse or not. I would think that you would not even want to attempt parsing the response data if there was a status code which indicated error.

If indeed the Seriously library is not filtering out responses with error status codes from being parsed, and will subsequently crash an app as soon as an error response is received, then that is a major bug, as the app can't crash whenever there's a server-side or network issue.

A response / help would be greatly appreciated!

Thanks,

Brad

Great lib, more OSX libs should be written in this style, with static methods and callbacks. One question, any interest in using yajl-obj rather than your own yajl code. The reason I ask is that I use (and presumably others may too) yajl-objc to create JSON from objects like NSDictionary when we have to do a HTTP POST. SeriouslyJSON can only parse JSON, not create it. I don't want to include 2 JSON libs in my apps. If I have to no big deal, but I would rather work around it, especially since yajl-objc might use a different yajl than Seriously. I think yajl-objc is a really good lib too but perhaps you don't want that dependency.

I’ve recently added Seriously to the CocoaPods package manager repo.

CocoaPods is a tool for managing dependencies for OSX and iOS Xcode projects and provides a central repository for iOS/OSX libraries. This makes adding libraries to a project and updating them extremely easy and it will help users to resolve dependencies of the libraries they use.

However, Seriously doesn't have any version tags. I’ve added the current HEAD as version 0.0.1, but a version tag will make dependency resolution much easier.

Semantic version tags (instead of plain commit hashes/revisions) allow for resolution of cross-dependencies.

Thanks!

The Clang analyzer shows this line in SeriouslyOperation as a potential leak. Is it?

I might be missing something here but it appears that the isCanceled property is supposed to override the default isCancelled functionality of NSOperation. However, that property has 2 l's not 1. So this is creating a second property and probably not working as intended. Can you confirm that's the case? I don't see how cancelation would work with the current code.

Hi there

Seriously cool :) I'm a big fan of Ruby and iPhone, so it makes instant sense to me!

Question: have you thought about handling caching scenarios? For example, fetching a resource that's already in a local cache (so no need for HTTP hop)?

T

Ld /Users/tyler/Library/Developer/Xcode/DerivedData/util-bffzcuykeutlaqebforclsttpdvq/Build/Products/Debug-iphonesimulator/util.app/util normal i386
cd "/Users/tyler/xcode projects/util"
setenv MACOSX_DEPLOYMENT_TARGET 10.6
setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk -L/Users/tyler/Library/Developer/Xcode/DerivedData/util-bffzcuykeutlaqebforclsttpdvq/Build/Products/Debug-iphonesimulator -F/Users/tyler/Library/Developer/Xcode/DerivedData/util-bffzcuykeutlaqebforclsttpdvq/Build/Products/Debug-iphonesimulator "-F/Users/tyler/xcode projects/util" -filelist /Users/tyler/Library/Developer/Xcode/DerivedData/util-bffzcuykeutlaqebforclsttpdvq/Build/Intermediates/util.build/Debug-iphonesimulator/util.build/Objects-normal/i386/util.LinkFileList -mmacosx-version-min=10.6 -Xlinker -objc_abi_version -Xlinker 2 -Xlinker -no_implicit_dylibs -D__IPHONE_OS_VERSION_MIN_REQUIRED=50100 -framework UIKit -framework Foundation -framework CoreGraphics -o /Users/tyler/Library/Developer/Xcode/DerivedData/util-bffzcuykeutlaqebforclsttpdvq/Build/Products/Debug-iphonesimulator/util.app/util

Undefined symbols for architecture i386:
"OBJC_CLASS$_Seriously", referenced from:
objc-class-ref in ClickMe.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)