How to determine the Http Method type being implemented for web service API

[Omkar Ramtekkar]

Hello,

I'm working on a project, where in I need to get the data from server through 
RESTful web services.
Server side people have implemented a few web services. I need to use those 
methods, but I'm not sure which http method to use "Get" or "POST".
If I use "GET" as http method and if the server web service is being 
implemented in "POST" then I get 404 or similar http error code.
Is there any way to find out the http method type being implemented for a web 
server API?
Right now I'm using a BOOL flag to determine which Http method to use. The flag 
is being set from outside.
NSMutableURLRequest *urlRequest = nil;

if (_usePostMethod)
{
urlRequest = [[NSMutableURLRequest alloc] initWithURL:self.serverURL 
cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:30.0f];;
[urlRequest setHTTPMethod:@"POST"];
[urlRequest setHTTPBody:[restMessage.message 
dataUsingEncoding:NSUTF8StringEncoding]];
}
else
{
urlRequest = [[NSMutableURLRequest alloc] initWithURL:[NSURL 
URLWithString:[NSString stringWithFormat:@"%@/%@", self.serverURL, 
restMessage.message]]
  
cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:30.0f];
[urlRequest setHTTPMethod:@"GET"];
}


I wanted to get rid of this BOOL _usePostMethod variable.

Thanks and Regards

Omkar Ramtekkar | Module Lead - Collaboration BU
omkar_ramtek...@persistent.co.in | 
Cell: +91-9730162294 | Tel: +91-712-398-6261
Persistent Systems Ltd. | 20 Glorious Years | 
www.persistentsys.com


DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Ltd. does not accept any liability for virus infected mails.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse

[Rick Mann]

On Jun 23, 2013, at 09:11 , Gordon Apple  wrote:

> On the original question asked in this thread,  I have several similar
> places where I use a root object to also persist an object selection in the
> referenced collection.  I could not see burdening the collection objects
> with another inverse relationship, so I just let these dangle, and ignore
> the compiler¹s complaints, because this is something that can usually be
> recovered from if there is a problem.

This is what I ended up doing. I wish there was a way to say, "Yes, I 
acknowledge this situation, no need to warn me about this one."


-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Ian Joyner]

Thanks for the reference to Codd's early paper. I'm researching the relational 
model now since I'm giving a course in distributed systems soon. In fact, I'm 
reading Codd's 1990 book "The Relational Model for Database Management Version 
2". It is available as a pdf (although I have had the physical book for years. 
Also good are any C.J. Data writings.

"An Introduction to Database Systems" says "SQL is not perfect. SQL is very far 
from being the perfect relational language - it suffers from numerous sins of 
both omission and commission". In particular it allows duplicate rows which 
lead to anomalies. It is a shame the relational model has come to be judged by 
SQL (rather like one could judge OO by C++). While Codd was a researcher at 
IBM, SQL was done by a committee at IBM, and is fundamentally tasteless. SQL 
also breaks the terminology and confuses tables with relations.

Codd 1990 has chapter 23 "Serious Flaws in SQL".

Other models have come along, like Entity-Relationship (ER) and OODBs, 
supposedly addressing the 'weaknesses' of relational. But they fail for all 
their heavy marketing. OO really gets back to network and hierarchical data 
models. It is also record-at-a-time oriented which was the pre-relational 
approach. This makes applications and users far more dependent on the structure 
of the data. While the relational model well expresses semantics, building in 
too much semantics is a mistake and makes what you might think of tomorrow more 
difficult because you built today's assumptions into the model. The approach of 
Hammer and McLeod (which resulted in Unisys SIM, which seemed a good idea at 
the time) really failed.

ER distinguishes entities and relationships. However, relationships are just 
modelled by the single notion of relation. For example, 'marriage' is a 
relationship between two people, but this is just as well modelled by a 
relation as an arrow between two people in the people relation. You can also 
add extra information like date-of-marriage and date-of-end, reason-for-end, 
etc in a relation, which you can't to an arrow. ER is imprecise in these 
matters. Codd covers this well in chapter 30 and Date in chapter 14. ER 
diagrams can be useful, but we should not confuse diagrams with goodness, 
especially when they lack formality (like UML).

Another book available for free online is Hugh Darwen's:

http://bookboon.com/en/an-introduction-to-relational-database-theory-ebook

He has done a lot of writing with Date on marrying relational with OO the 
correct way (The Third Manifesto).

Perhaps all this answers the original "inverse relationship" question by saying 
relational doesn't have relationships other than by relating data values. That 
is there are no rat's nest pointers making the system brittle. I'd have to do 
some more thinking as to whether that is a weakness in CoreData or not, but it 
seems to be erring in the ER direction.

On 23 Jun 2013, at 11:04, Michael Crawford  wrote:

> Relational Databases and Databases in general are two different things.
> 
> E. F. Codd proposed Relational Databases in a 1970 Communications of
> the ACM paper that turned up instantly in a search.  Here's a PDF:
> 
>   http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
> 
> That paper itself says nothing at all about SQL, which is used to
> communicate between the database and either the end user, or software
> that acts on behalf of the end user.  Instead it discusses the logical
> structure of Relational Databases, with only databases that have that
> certain kind of structure being considered "Relational".
> 
> Part of that, for example, is the notion that there should be only one
> copy of any given item of data.  Say you stored Steve Wozniak's
> payroll information, and you put his salary in two different fields
> because it was convenient to do so, either because the client code was
> easier to write, or the data could be retrieved or stored more quickly
> that way.
> 
> Inevitably some innocuous error would result in the two copies
> becoming different from each other, and there would be Hell to pay.
> 
> There's a lot more to it than that.
> 
> Codd himself many years later - just a few years ago - spoke of his
> great disappointment with SQL, pointing out that SQL all by itself
> does not make any database at all Relational.  That's up to the
> database architect who designs its schema.  There are some things that
> the database vendors must implement, such as atomic and fault-tolerant
> storage, but any fool can create an Oracle or MySQL database that's
> not Relational by designing the tables, rows and columns in some
> manner of incorrect way.
> 
> There are many kinds of databases that are really great, but that
> don't even attempt to be Relational.
> 
> Mike
> 
> On Sat, Jun 22, 2013 at 3:03 PM, Charles Srstka
>  wrote:
>> On Jun 22, 2013, at 10:43 AM, Michael Crawford  wrote:
>> 
>> I don't use Core Data because it's not cross-platform.  In my honest
>> opinion

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Ian Joyner]

On 23 Jun 2013, at 13:32, "Reaves, Timothy"  
wrote:

> What the docs state that is meaningless (although inaccurate); the
> Objectice-C manual could very easily state that Objective-C is not a
> programing language; it is.  CoreData is a database.

OK, what the Apple doc 
http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html%23//apple_ref/doc/uid/TP40009296-SW1
 says:

"Core Data is not a relational database or a relational database management 
system (RDBMS).

"Core Data provides an infrastructure for change management and for saving 
objects to and retrieving them from storage. It can use SQLite as one of its 
persistent store types. It is not, though, in and of itself a database"

I agree with you in the general sense, but I think the docs are speaking in the 
more specific sense. CoreData is really the middleman which can interface to a 
number of data stores. To think of a database as a data store is also 
misleading because the relational model is very high-level and very abstract 
and about as far away from data store as you could get.

CoreData is more a modelling system (I could say data model... but it's not 
that either). Thus programmers should be abstracted away from the physical 
storage medium (which I think is a point you are making).

However, CD does rather look like the entity-relationship model, which is 
fundamentally broken by distinguishing between entities and relationships and 
lacks precision and formality (correctness and flexibility) which the 
relational model has.

So in one sense you are right it is a database, but I'd say more a definer of 
data models and these happen to get stored somewhere in a database. But CD is 
not that database itself - it is the glue between the DB (or in-memory store) 
and an application program.

>  A database need never
> write anything to a file.  There are - in fact - several examples, of all
> manor, of in-memeory data bases that never bother to persist to a file.  As
> the documentation points out, there are five(?)(XML, plist, SQLite, iCould,
> in-memory) supported backing stores.  Four will cause a file to be created,
> and one will not.
> 
> Yes, it's fully possible for CoreData to be broken into two components; one
> that manages object graphs, and one that manages persisting them.  But
> until that time, CoreData is a framework/library/module with the intention
> of causing data to be stored, even if only in memory. That, by definition,
> makes it a database, and when at least one particular backing stores is
> used, it also makes it an ORM.  That it can do other things is irrelevant.
> 
> Now, enough with the philosophy!  :-D
> 
> 
> 
> 
> 
> On Sat, Jun 22, 2013 at 4:19 PM, Luther Baker  wrote:
> 
>> ... yes, and if you are going to be pedantic, please be somehow consistent
>> with the docs:
>> 
>>> Core Data provides an infrastructure for change management and for
>> saving objects to and retrieving them from storage. It can use SQLite as
>> one of its persistent store types. *It is not, though, in and of itself a
>> database.* (To emphasize this point: you could for example use just an
>> in-memory store in your application. You could use Core Data for change
>> tracking and management, but never actually save any data in a file.)
>> 
>> 
>> http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html#//apple_ref/doc/uid/TP40009296-SW1
>> 
>> 
>> 
>> 
>> On Sat, Jun 22, 2013 at 1:26 PM, Timothy Reaves <
>> trea...@silverfieldstech.com> wrote:
>> 
>>> Yes, CoreData is a database, and it does do ORM.  It's not just an ORM,
>>> and it's not an RDBMS.
>>> 
>>> If it wasn't a database, it couldn't store data; that is the definition
>>> of a database. A database is not something that has row, columns, etc; it's
>>> something that stores data in an unspecified manor.  Yes, and ASCII file
>>> can be a database, as many, many are on the mainframe.  You seem to be
>>> confused as to what a database is.
>>> 
>>> If CoreData didn't do ORM, it couldn't persist objects into a SQL
>>> database, which it does with SQLite.  It is not 'just' an ORM, and the ORM
>>> features may be optional, but they are still there.
>>> 
>>> If you are going to be pedantic, be accurate in your pedanticism.
>>> 
>>> 
>>> 
>>> 
>>> On Jun 22, 2013, at 10:37 AM, Kyle Sluder  wrote:
>>> 
 On Jun 22, 2013, at 12:55 AM, Rick Mann  wrote:
 
> 
> On Jun 22, 2013, at 00:50 , Keith J. Schultz 
>>> wrote:
> 
>> Core data helps in setting up the database, but deleting is another
>>> matter.
>> You should do that manually for consistency. Core Data has no
>>> knowledge of the
>> semantics of your database. so use prepareToDelete.
 
 I'm sorry, but what?
 
 1. Core Data is NOT a database. It is NOT an ORM. Core Data is a model
>>> object persistence and management framework. It just so happens that it can
>>> use a SQLit

Re: Getting the location of the Library

[Kyle Sluder]

On Jun 23, 2013, at 1:49 PM, Pax <45rpmli...@googlemail.com> wrote:

> Just a quickie, I hope!  I'm writing a sandboxed application that uses 
> plugins.  The plugin directories that I want to load from are 
> '/Library/Application Support/MyApp' and '~/Library/Application 
> Support/MyApp'.

You do not have access to these locations from within a sandboxed app.

The recommended way forward is to use a container migration manifest to move 
files in these locations into your container. It is then your app's 
responsibility for presenting a user interface for managing these files.

An alternative is to request a temporary entitlement for the directories you 
wish to access, and then use getpwuid to find the user's home directory. You 
cannot consider this a permanent solution, and should consider offering the 
migration approach as an alternative (perhaps as an in-app process hiding 
behind a confirmation dialog).

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting the location of the Library

[Ben Kennedy]

On 23 Jun 2013, at 2:32 PM, Ben Kennedy  wrote:

> I haven't tested anything, but just looking at this line, I am inclined to 
> guess the subtraction is your problem.  If your intent is to choose all 
> domains except for the system domain, you'll need to XOR the value, not 
> subtract it, i.e. (NSAllDomainsMask ^ NSSystemDomainMask).

I'm sorry -- this is not helpful advice; given the values in question, both the 
subtraction and the xor yield the same result.  I should have realized this.

Instead I'll submit a replacement suggestion: what happens if you ask for 
NSApplicationSupportDirectory instead of NSLibraryDirectory?  From the 
description of your problem, this sounds like more what you're actually after.

b

--
Ben Kennedy, chief magician
Zygoat Creative Technical Services
http://www.zygoat.ca


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting the location of the Library

[Ben Kennedy]

On 23 Jun 2013, at 1:49 PM, Pax <45rpmli...@googlemail.com> wrote:

> The code I am using to get the location of the Library is:
> NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSAllDomainsMask - 
> NSSystemDomainMask, YES);

I haven't tested anything, but just looking at this line, I am inclined to 
guess the subtraction is your problem.  If your intent is to choose all domains 
except for the system domain, you'll need to XOR the value, not subtract it, 
i.e. (NSAllDomainsMask ^ NSSystemDomainMask).

b

--
Ben Kennedy, chief magician
Zygoat Creative Technical Services
http://www.zygoat.ca


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Getting the location of the Library

[Pax]

Just a quickie, I hope!  I'm writing a sandboxed application that uses plugins. 
 The plugin directories that I want to load from are '/Library/Application 
Support/MyApp' and '~/Library/Application Support/MyApp'.
I don't really care if  
'~/Library/Containers/com.myapp/Data/Library/Application Support/MyApp' is 
included or not - since it's not a location that the users of my app are likely 
to think of when adding or removing plugins.

The code I am using to get the location of the Library is:
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSAllDomainsMask - 
NSSystemDomainMask, YES);

This returns '/Library' and '~/Library/Containers/com.myapp/Data/Library' - 
which is not entirely what I'm after.  How can I get '~/Library' as well?  Am I 
just going to have to work this out for myself, or is there a ready made 
function that I can use to get this for me?

Thanks for any help that you can provide.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Sean McBride]

On Sat, 22 Jun 2013 08:43:09 -0700, Michael Crawford said:

>I don't use Core Data because it's not cross-platform.  In my honest
>opinion no one in their right mind would bet their livelihood on
>platform-specific document formats, no matter what the platform.

The Core Data persistent store formats Apple provides are unfortunately 
undocumented yes, but I believe you can subclass NSPersistentStore and persist 
your data in whatever format you want:



"This document describes how to use the atomic store API to create custom 
persistent stores for Core Data applications.  You should read this document if 
you want to create a Core Data persistent store for which you manage the file 
format."

I've never tried, but hopefully it works.

Maybe a kickstarter project to create a nice NSPersistentStore would be better. 
:)

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse

[Gordon Apple]

I try to minimize my dependency on CoreData by using generic and
app-specific categories on the MOC.  I also mostly use root entities, rather
than doing independent fetches.  I had looked at other options, but
pragmatism won out, and I went with CoreData.

You mentioned MacApp.  I was heavily involved in that for awhile and even
got into the credits.  I don¹t know if you remember Bob Krause.  When I was
running the developer sig at LA Mac Group, I had him down for a presentation
on his object database backend, NeoAccess.  He had a version for MacApp, but
I believe he also had one for Next Step.  I tried to get Apple, Inc. to look
into it, but I guess they decided to go with their Enterprise Objects to do
CoreData instead.  I wish they would take another look and consider doing a
true object database engine using more of a CORBA-type interface, which, I
believe, was attempted by Taligent, before Jobs killed it.

On the original question asked in this thread,  I have several similar
places where I use a root object to also persist an object selection in the
referenced collection.  I could not see burdening the collection objects
with another inverse relationship, so I just let these dangle, and ignore
the compiler¹s complaints, because this is something that can usually be
recovered from if there is a problem.


On 6/22/13 2:00 PM,  Michael Crawford  wrote:

> I don't use Core Data because it's not cross-platform.  In my honest opinion
> no one in their right mind would bet their livelihood on platform-specific
> document formats, no matter what the platform. I used to be a Senior Engineer
> at Apple.  Many of my best friends still work for Apple.  But I remember
> Bedrock.  I remember MacApp.  I actually led the effort to specify an Apple
> Events Suite, along with a bunch of my employer's competitors.  The Word
> Services Suite still works completely unmodified in Mac OS X, despite my
> having written the spec in 1992.  Now try to find any mention of Apple Events
> in any of Apple's documentation. While one can use SQLite or XML for the
> storage, if the SQLite or XML documents are to be opened on some other
> platform, one would have to write all that code from scratch, without the use
> of Core Data. Instead for SQLite, I just write the SQL directly, and for XML,
> I use Xerces-C (actually C++) to create a DOM tree (Document Object Model) in
> memory, then serialize it to an XML file.  The inverse process reads XML then
> creates an in-memory DOM tree. For large files, Xerces-C also implements SAX
> (Simple Architecture for XML), which uses callbacks for each item in the file;
> say for XHTML, one would have a  handler, a  handler, a 
> handler, a  handler and so on.  It's more difficult to write Sax code,
> but it's far faster and uses far less memory than DOM. Mike


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: fast search of NSPointerArray

[Keary Suska]

On Jun 22, 2013, at 9:25 PM, James Maxwell wrote:

> t's a mixed graph structure. Basically, I'm storing all unique nodes in an 
> NSMutableArray, then using NSPointerArrays to build the adjacency lists. It 
> works really nicely for learning/building the graph, but it does seem as 
> though searches are a little slower. My guess is that this is because I'm now 
> iterating over a lot of null values (which I wasn't before). But, as Graham 
> says, I should really verify this before going any further with altering the 
> data structures...

You might also want to consider as you are profiling that the issue may simply 
be the need to iterate and that a non-linear approach would work better. After 
you have determined where the performance issue is, posting a graph of your 
data structure and what it represents, including how it needs to be modified 
throughout its lifetime would allow listers to make recommendations on 
structure.

Notwithstanding the performance issue, it may be useful to periodically compact 
the pointer arrays. Some heuristics could be employed to minimize its impact on 
the user experience; e.g. at save time.

HTH,

Keary Suska
Esoteritech, Inc.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Scott Ribe]

On Jun 22, 2013, at 7:38 PM, Michael Crawford wrote:

> If you claim you know how to estimate software development
> time and cost, I don't believe you.

I do, and I do *very* well at it. But I certainly cannot estimate 
reverse-engineering an undocumented format; it would be madness for anyone to 
claim otherwise ;-)


-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com