Re: LGPL code in the Mac App Store?
I think that this is a slightly uncharitable view of OSS devs, but not terribly inaccurate. > On Jan 29, 2016, at 1:30 PM, Quincey Morris > wrote: > > On Jan 29, 2016, at 09:27 , thatsanicehatyouh...@me.com wrote: >> >> One thing I forget to add; probably the *very best way* to address this >> issue is to contact the library author and say, “Hey, I want to use your >> LGPL code in my Mac app and put it on the App Store; is that ok? Do you mind >> if people can’t dynamically link their own copy, because really, no one will >> want to?” > > This is rational, but unfortunately doing this makes the library *free* > software, not *open source* software. > > The open source “hook” — what makes it attractive for a public spirited > programmer to make it available to everyone — is that it permits others to > play with the code downstream. That means (say) faster versions of the > algorithms, or the extraction of intermediate results for interesting new > uses, etc. Humanity is benefitted. > > This doesn’t work with the above suggestion. In fact, the library author is > likely to say, “Hey, I wrote this software, and you’ve made it an essential > component of your app, and you’re *selling* the app and making yourself rich > with the money??? Gimme some.” > > I think a better technical approach would be to embed the library as a > framework in your app, but arrange that if a version of the framework is in > (say) /Library/Frameworks, that one is dynamically loaded instead of the > built-in framework. You might also need to be able to provide the source code > of the version you embedded, but it would be easy for users to substitute > other (ABI-compatible) builds for yours. > > The problem is that I don’t think there’s a mechanism for doing this. The > path to the embedded framework is baked into the app, I believe, and you > can’t change it without invalidating the code signature of the app. Further > it would be a horrible security hole if you could simply override any > embedded framework in any with an external hacked one. > > However, for designated frameworks, if there was a way — I dunno, an > environment variable you could set — to adjust the load location of just > those frameworks, the result would be approximately in the spirit of the > LGPL. > > But I’m certainly not holding my breath on this. > > ___ > > 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/dru%40druware.com > > This email sent to d...@druware.com ___ 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: LGPL code in the Mac App Store?
Keep in mind that LGPL restrictions got tighter in v3, and I know there remain many projects out there that are LGPL but have refused v3 for these reasons. > On Jan 29, 2016, at 11:28 AM, thatsanicehatyouh...@me.com wrote: > > Hi, > > Thanks to everyone who answered or commented on this question. This is my > understanding of one path forward. (And everybody sing along, I am not a > lawyer, and the fact that the license is so convoluted that almost literally > everyone feels the need to make this disclaimer is one of the things that > really annoys me about GPL…). > > * LGPL code should be placed into its own framework and be dynamically loaded. > * It can be distributed in this manner in the Mac App Store. > * Create an Xcode project that builds the framework (along with the source > files) into a public GitHub repository. Make this a dependency of your > application project. > * Mac App Store apps cannot load executable code not signed (i.e. delivered) > by the app. > * The LGPL license requires that users have the ability to modify the LGPL > part and link that to the app. Users are free to download the framework > source from GitHub, modify it (without changing the API) and build it. They > can then strip all the code signing from the app, replace the framework in > the app bundle, and run. This should satisfy the letter of the license. (Of > course no one will ever do this. I am assuming this process doesn’t strip the > DRM as well!) > > I’d be happy to hear about a better/easier way to satisfy the last point > while still distributing through the App Store. > > Cheers, > Demitri > > > ___ > > 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/dru%40druware.com > > This email sent to d...@druware.com ___ 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: LGPL code in the Mac App Store?
There are/were some restrictions on GPL, but even those often go through and only get removed in the instance of a dispute. I think there has been some redressing of specific language in the GPL to address the issues. LGPL should be fine though, and there is a fair amount go GPL code in AppStores, so i don’t think it is the issue it is sometimes made out to be. > On Jan 27, 2016, at 11:47 AM, Jens Alfke wrote: > > >> On Jan 26, 2016, at 10:59 PM, Pascal J. Bourguignon >> wrote: >> >> Sorry, I thought the context was iOS (and therefore distribution thru the >> AppStore). > > I still don’t see why you wouldn’t be able to submit an app to the store that > contains LGPL code. For one thing, Apple’s reviewers have no way to identify > the license or ownership of the source code since they only see the binary. > For another, as I said, the license is an agreement between you the developer > and the owner of the source code, and Apple has no part in it. > > —Jens > ___ > > 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/dru%40druware.com > > This email sent to d...@druware.com ___ 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: LGPL code in the Mac App Store?
Now you are getting into the nitty gritty of LGPL wording and implementation, at that point, it becomes more about working with the copyright holder to ensure you are complying with the intended spirit of the license, or engaging a lawyer to get him to sign off on a willingness to defend the implementation in courtroom. I know a lot of people denigrate the LGPL without enough information, but to me, this is the real issue with the LGPL as it stands. There remains too much grey area. That said, I’m with Jens. an embedded .dylib meets the letter of the LGPL. IIRC, the question of static linking against a .a has also been upheld, so long as application provides value above the library, and the app could function (albeit with lesser functionality) if built without the library. On Jan 26, 2016, at 4:33 PM, Jens Alfke mailto:j...@mooseyard.com>> wrote: y the terms of the license. It’s not like a lot of actual users are going to be replacing the library, so there’s no point going to more work to make ___ 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: [Solved] Re: Storing UTF8 Umlauts in Postgres using PGSQLKit
Sorry I didn't see this, I was KO'd by the pollen and seasonal allergies. Yes
this is an issue with PGSQLkit, I have confirmed it and will be committing a
change today based upon yours to address this. Thanks for patch!
--
Andy 'Dru' Satori
On Thursday, March 22, 2012 at 6:55 AM, Alexander Reichstadt wrote:
> The issue was in PGSQLKit.
>
> -(NSString *)sqlEncodeString:(NSString *)toEncode
> {
>
> //size_t result;
> int error;
> char *sqlEncodeCharArray = malloc(1 + ([toEncode length] * 2)); // per the
> libpq doc.
> const char *sqlCharArrayToEncode = [toEncode
> cStringUsingEncoding:defaultEncoding];
> size_t length = strlen(sqlCharArrayToEncode);
>
> PQescapeStringConn ((PGconn *)pgconn, sqlEncodeCharArray,
> (const char *)[toEncode cStringUsingEncoding:defaultEncoding],
> length, &error);
>
> //This is bad
> // NSString *encodedString = [[[NSString alloc]
> initWithFormat:@"%s",sqlEncodeCharArray] //autorelease];
> //Instead use
> NSString *encodedString = [NSString stringWithCString:sqlEncodeCharArray
> encoding:defaultEncoding];
>
> free(sqlEncodeCharArray);
>
> return encodedString;
>
> }
>
>
>
>
> Am 22.03.2012 um 09:09 schrieb Alexander Reichstadt:
>
> > Hi,
> >
> >
> > for a couple of reasons we migrated our project from mysql to postgres
> > using PGSQLKit.
> >
> > But we are experiencing problems storing UTF8 data. So far we checked the
> > database to be able to store UTF8. When using pgPHPAdmin to store values
> > with German Umlaute it works. When using PGSQLKit chars get garbled.
> >
> > The following code stores the values:
> >
> >
> > const char *cString = [sql cStringUsingEncoding:NSUTF8StringEncoding];
> > if (cString == NULL)
> > {
> > self.errorDescription = [NSString stringWithFormat:@"ERROR: execCommand
> > could not be losslessly converted to c string: %@", sql];
> > [self appendSQLLog:[NSString stringWithFormat:@"%@\n",
> > self.errorDescription]];
> > return NO;
> > }
> > res = PQexec(pgconn, cString);
> >
> > Both sides seem correct, server as well as client, so I am not sure what
> > the issue might be.
> >
> > Any ideas?
> >
> > Thanks
> > Alex
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com
> > (mailto: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
> > (http://lists.apple.com)
> >
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/lxr%40mac.com
> >
> > This email sent to l...@mac.com (mailto:l...@mac.com)
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com
> (mailto: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
> (http://lists.apple.com)
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com
>
> This email sent to d...@druware.com (mailto:d...@druware.com)
___
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: Closing an app with the red dot.
This is a classic instance of having to look at the nature or the application to decide if it is an appropriate action. I use both models depending upon the application. The general approach I take is to look at the app in question determine if there is any legitimate reason it should stay open when the main window is closed. EG. Suppose the application is a simple dialog based app, take for example an app I use once or twice a week to decrypt Cisco Group Names from .ini config files. Once I've displayed the decrypted password on screen, and closed the window, should the app remain loaded? I would argue no. it is small enough that reloading it is not an issue, so closing the last window closes the app. The inverse of this is a document based app. I cannot come up with many reasons a document app should ever exit when the last document window is closed. This is counter to how Windows devs would function and as many new MAc devs bring some of those notions, it is something to be aware of. In other words, think long and hard before implementing a behavior that is non-standard to the platform, or you quickly find yourself in the 'Why am I using an app tthe feels like a Windows App on the Mac?' conundrum -- Andy 'Dru' Satori On Tuesday, May 17, 2011 at 11:40 AM, Uli Kusterer wrote: > On 17.05.2011, at 14:54, Andy Lee wrote: > > On May 17, 2011, at 8:44 AM, Andy Lee wrote: > > > Also you can implement the > > > applicationShouldHandleReopen:hasVisibleWindows: method mentioned above > > > to automatically reopen the window, if you prefer. > > > > Though I'm not sure as a user I'd like that. Maybe that is what people > > meant when they said "that is the way Mac works". > > Doesn't matter what you like as a user, you're a programmer :-p > > Seriously, many applications on the Mac work that way. Close all windows in > Mail.app and click on the dock: Presto! New mail window. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.masters-of-the-void.com > > > > ___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Need HTTP Server & JSON recommendations
Though there are several options to do this within your application from scratch, I think it is a bad idea. Security is an ever increasing problem, and rolling your own httpd server is kinda risky when there are ready made options out there. Because of this, I embed the open source and commercially viable BSD licensed lighttpd. The downside to this is that you have to be creative with handling the requests now. Cgi in the httpd server is the easiest way to go. Using fastcgi, it is fairly easy to implement a tool the will respond to the requests using a foundation tool too access your existing cocoa classes. This is how I am implemented in a couple of my projects and I have been very pleased with performance, but it can be tricky to set up the first time in your design. Once you get it worked out, it is powerful, and you can deploy single app bundle without haveing to write your own web server. Andy 'Dru' Satori - all typos courtesy of fat finger and an iPad On Dec 6, 2010, at 12:21 PM, Todd Freese wrote: > I have an existing CoreData app that now needs to share it's data via JSON. > Can anyone recommend a framework or sample code that would include a simple > HTTP server? I googled and found a bunch of JSON frameworks which look great. > The part I need help with is the HTTP server. > > Any suggestions or recommendations would be appreciated! > > Todd > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ > ___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: JDBC from Cocoa or the like
I have made freetds work on iOS. It is doable, and it is usable. I never did anything with it because greeted is gpl, so turning it into a commercial product on the AppStore presented non technical "challenges". I also have PostgreSQL client Libraries working on iOS. If you want help with this, I will be happy to talk about it, but ODBC is, IMO a bad fit for iOS at many levels. In truth I think all traditional DBMS toolkits have issues in the long run on iOS. They are fine so long as the devices are on wifi within the walls. Once they go outside the walls, and you go from wifi bandwidth and latency levels to 3G or edge, these models quickly become horrible fits with the iOS model. The problem is that *all* of the protocols, be it TDS, ODBC (which for MSSQL is still TDS), libpq, et al are designed for low latency, high bandwidth connections. They are chatty and are not optimized for running over spotty and intermittent 3g connections. A VPN does not fix the fundamental weaknesses in the wire protocols. Any MSSQL admin that has more than a couple of years of experience has seen the intermittent SSPI and connection drop errors that happen on LAN's when you get a lot of line noise (a saturated hub will often timeout otehr computers on the same hub). Because of this, I strongly advocate n-tier solutions for iOS devices, but I understand the reasons that they are often not options. That is why I have done the legwork on other options. If MSSQL is your destination, then FreeTDS is your best option. You may/probably will need to work with FreeTDS.org to obtain a commercial usable license, but in terms of usability and perfomance, it is fine (within reason). Please do not misunderstand me, I am probably one of the biggest RDBMS advocates in this community (PostgreSQLforMac, ODBCKit, PGSQLKit, and the unreleased TDSKit are all my projects), but when it comes to iOS, I just do not feel that the existing client libraries are the best solution. Andy 'Dru' Satori On Oct 6, 2010, at 10:47 AM, colors wrote: > Alex, > > I have the same problem you document below, so looked into your ODBC > reference. However, it looks like they want to sell me a $2000 router > software package to work with the iOS. What I need is a framework (much like > easyDB, but allowed to be used on a commercial product). Did I miss-read the > web site? > > Rich > > On Oct 5, 2010, at 9:39 AM, Alex Kac wrote: > >> I saw this ODBC framework for iOS. Maybe that helps as well: >> http://www.prlog.org/10938886-open-database-connectivity-odbc-arrives-for-apple-ipad-iphone-and-ipod-touch.html >> >> One problem I've always had with the N-tier arch is that of customer >> security. Many companies simply won't use an app that doesn't talk directly >> to the database within their own private VPN/network. >> >> On Oct 5, 2010, at 11:09 AM, Kyle Sluder wrote: >> >>> On Tue, Oct 5, 2010 at 9:03 AM, colors wrote: >>>> Is there a framework, or set of APIs or samples available from Apple or >>>> others to do SQL server accesses? I have looked at easyDB, but its >>>> license makes it a non-starter. I have also looked at freetds, but it >>>> does not look like it is ready for prime time (let along particularly good >>>> in the Mac support arena). To make maters a little harder, I need to have >>>> it work on the iOS too. >>> >>> If you didn't need it to work on iOS, you could use ODBC. >>> >>> Why not adopt a classic N-tier architecture, and have a service with >>> which your apps can communicate rather than having them talk to the DB >>> directly? >>> >>> --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: >>> http://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net >>> >>> This email sent to a...@webis.net >> >> Alex Kac - President and Founder >> Web Information Solutions, Inc. >> >> "Forgiveness is not an occasional act: it is a permanent attitude." >> -- Dr. Martin Luther King >> >> >> >> > > ___ > > 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 > &
Re: Cocoa Newbie & MySQL
Yes, Marko's BaseTen is excellent, and the PostgreSQL support for the Mac as a platform is quite good. The only downside really, is that there is an outstanding issue with regards to collation in certain locales on BSD based systems, of which OS X is one, so long as you are us_EN and UTF-8, you'll be fine, but there are issues with the us_FR and a few others. Andy 'Dru' Satori On Apr 29, 2010, at 12:53 PM, Joshua Tidsbury wrote: > Flavio, >> Well... That's a good enough reason. Driving that Sun stuff through exec() >> and command-line utilities should be extremely painful and hard to maintain >> in the future. >> > Indeed, I did consider that for about 5 seconds, then smacked myself in the > forehead... >> Do you really need to use MySQL -- or any other full-fledged RDBMS? I am not >> sure how big will be your dataset, how often it will be updated and how many >> users you'll have, so I can't help that much. >> > We're looking at about 100 users (for now), and a dataset starting at about 3 > million rows. This will grow steadily through the years though, at a rate of > about 3+ million rows per year. >> If you really need an RDBMS, you could consider PostgreSQL and the BaseTen >> framework (basetenframework.org). It feels a lot like Core Data, but for >> Postgres. >> > I actually had my head buried in the sand solely thinking of MySQL, only for > sake of familiarity. But this framework looks fantastic - I'll play around > with it and see what I can come up with. And I have little doubt that > PostgreSQL has plenty of power to pull this sort of project off. >> Why do we, developers, love challenges? ;) >> > The question of the ages :) > > Take care, > Josh___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa Newbie & MySQL
Well, the short version is CoreData & SQLLite will not help you in any way with MySQL. As to using another framework or rolling your own, that largely depends upon your needs. Obviously the GPL is not an issue if you are going against MySQL anyways, so I would probably look hard at not reinventing the wheel and using a preexisting framework. Andy 'Dru' Satori On Apr 27, 2010, at 9:04 PM, Joshua Tidsbury wrote: > Hello everyone, > > I'm in the process of developing one of my first Cocoa applications, and I'm > looking for some advice to keep myself from wandering into the wrong > direction. > > The application I am going to be writing ultimately needs to access MySQL as > a datastore. I'd love to go with Core Data and SQLite, but based on some > reading, SQLite wouldn't be ideal if multiple clients were to be accessing > the same datastore. > > So, the question is this: Would I be advised to use the MySQL C API and write > my own wrappers or use the slightly more recent mysql-cocoa framework at > http://code.google.com/p/mysql-cocoa-framework/ ? Or perhaps a third option > I am unaware of? > > Many thanks, > Josh > > > Joshua Tidsbury | Systems Specialist, Creative Technology Systems > t 416.384.7253 | m 416.433.3968 | joshua.tidsb...@ctv.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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Data managment
Honestly I am surprised that apple has not adopted one of the OSS database engines as a standard db in osx and implemented core data on top of it for multi user implementations. If for no other reason than to shoot at Microsoft over the mssql as part of the file system debacle Andy 'Dru' Satori On Apr 12, 2010, at 2:08 PM, Jens Alfke wrote: > The @*$& listserv is stripping the HTML from messages, so the links in my > previous post got lost. (I guess hyperlinking is too newfangled a concept for > Mailman?) > > CouchDB: http://couchdb.apache.org > Ubuntu DesktopCouch: > http://www.freedesktop.org/wiki/Specifications/desktopcouch > > —Jens ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Data managment
I looked at it pretty hard, but in the end I went with a traditional RDBMS, largely for the eventual need to expose the interface to external reporting tools, that as a rule don't talk custom interfaces. Admittedly, I borrowed some concepts though. Design wise the 'server' in my configuration is PostgreSQL->Cocoa Business Objects exposed via web services ( custom fastcgi interface running in an embedded instance of lighttpd using SOAP for compatability with a possible .NET client ) that even in single user mode passes all data requests via http. It is a solution. It has quirks, but the long term, I think it is a design that we will see more and more of. CouchDB is very very slick, but it has some issues behind the scenes particularly in terms of performance. Andy 'Dru' Satori On Apr 12, 2010, at 2:05 PM, Jens Alfke wrote: > > On Apr 12, 2010, at 10:54 AM, Dru Satori wrote: > >> One application that can be used standalone, or always on multi-user or with >> multiple disconnected users synchronizing data when peered. Complex? You >> have no idea. But in the design process, many decisions had to be made, >> that meant architecture and implementation. The end result for me? a >> client server design that uses a multi-user capable database engine even >> when in stand-alone single user mode. When you start the application, it >> starts the embedded database engine. While this is massive overkill for >> most implementations, it is still a very real design, IF your project >> demands it. > > Veering a little off-topic, but have you looked at CouchDB? It's a very cool > persistent data store that works either single-user, multi-user, or > replicated. It's kind of a fancy JSON-based key-value store with MapReduce > based querying, and a fancy sync engine for connecting multiple instances. > > I haven't seen any usage of CouchDB by Mac apps yet, but it's already been > integrated into Ubuntu Linux's desktop as the underlying shared data store > for contacts and calendars and so on — like a combination of the AddressBook > and Calendar frameworks and iSync. This is one of the few times I've been > jealous of Linux's UI. :) > > The CouchDB protocol is pretty easy to work with because it's all > HTTP/REST/JSON. You'd mostly just need NSURLRequest and one of the Cocoa JSON > parsers. > > —Jens ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Data managment
Another consideration is: Is this a project that could ever need a multi-user or networked data engine? If the above answer is yes, then CoreData is probably a bad option (though Marko's excellent BaseTen for PostgreSQL might be an option in that case), as the options for migrating Managed Objects to network databases are limited. That is part of the problem, 'Data' is such a relative term, and without knowing the goal of the application, it is tough to provide a good scalable alternative. From first hand experience, one of the projects I am working on is in some of this box. One application that can be used standalone, or always on multi-user or with multiple disconnected users synchronizing data when peered. Complex? You have no idea. But in the design process, many decisions had to be made, that meant architecture and implementation. The end result for me? a client server design that uses a multi-user capable database engine even when in stand-alone single user mode. When you start the application, it starts the embedded database engine. While this is massive overkill for most implementations, it is still a very real design, IF your project demands it. Andy 'Dru' Satori On Apr 12, 2010, at 12:33 PM, Jens Alfke wrote: > > On Apr 12, 2010, at 7:36 AM, Billy Flatman wrote: > >> Is it possible to get core data data models to save differently, one for a >> document save which for example might be an XML format, and one into the >> applications bundle as an SQLite file? >> That way when a document is saved the main database won't be duplicated, >> just the document specific data. > > You can have different documents with different data models, without needing > to use different on-disk data formats. In other words, you can have two > different document types both of which use SQLite. > > CoreData is very powerful, but it’s going to take over your app — you’ll end > up writing everything using managed objects and bindings. Which can be good, > but there’s a whole ‘nother learning curve for that. It can be easier to just > use a data storage API directly even if it doesn’t get you all the bells and > whistles. > > If you want to go with SQLite, you might consider using one of the Cocoa > adapter libraries so you can use an Objective-C API and not have to deal with > translating between char* and NSString all the time. The two I know of are > FMDB and QuickLite. > > There are also other data storage libraries that have a simpler data model > than sqlite (they’re like on-disk NSDictionaries) so they’re a bit simpler to > use and can potentially run faster. Tokyo Cabinet seems like the main > contender in that area right now. It comes with C and C++ APIs; I don’t know > if anyone’s adapted it to Objective-C yet. > > —Jens___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Data managment
So long as the application is single user, core data or sqlite are both excellent options. I personally prefer sqlite, as I find it easier to work with than core data. The problem I have with core data is that it's usage is so tightly wound to the managed object interface, that is can be difficult to come to grips with after years of working directly with SQL in other worlds. Andy 'Dru' Satori On Apr 12, 2010, at 9:38 AM, Billy Flatman wrote: > Hi all, > > I'm trying to find the best approach to data storage with a cocoa application. > I've got my application working and saving document specific data to a file, > but I also need a larger data file of persistent data, that shouldn't be > duplicated. I'm considering imbedding an SQLite database into my application, > but wasn't sure if I could use core data some how. > > Thanks > > Billy Flatman > b.flat...@googlemail.com > > > ___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Using a SOAP Web Service from iPhone
In this particular case, they do not, but you are correct, it should filter / encode those values. As I said in the mail, it hasn't been reviewed that heavily yet. It probably leaks like a sieve too :-) Andy 'Dru' Satori On Apr 9, 2010, at 12:59 PM, Jens Alfke wrote: > > On Apr 9, 2010, at 8:52 AM, Dru Satori wrote: > >> [soapRequestXml appendFormat:@"\t\t\t<%@>%@\n", paramName, paramValue, >> paramName]; > > Minor note: I hope none of your parameter values contain any XML > metacharacters like quotes or angle-brackets, or you’re going to at minimum > generate invalid XML, and at worst (if the values might come from an > untrusted source) open yourself up to XML injection attacks. > > —Jens ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Using a SOAP Web Service from iPhone
RI qualifiedName:(NSString *)qName
attributes:(NSDictionary *)attributeDict
{
BOOL isElementOfNote = NO;
// if this is not the response, go ahead and get out
if ([elementName rangeOfString:@"ValidateLoginResult"].location !=
NSNotFound)
{
isElementOfNote = YES;
}
if ([elementName rangeOfString:@"iCRMUserId"].location != NSNotFound)
{
isElementOfNote = YES;
}
if (isElementOfNote)
{
NSLog(@"starting Element: %@", elementName);
if (inprocessString != nil)
{
[inprocessString release];
inprocessString = nil;
}
inprocessString = [[NSMutableString alloc] init];
}
}
- (void)parser:(NSXMLParser *)parser
didEndElement:(NSString *)elementName
namespaceURI:(NSString *)namespaceURI
qualifiedName:(NSString *)qName
{
BOOL isElementOfNote = NO;
if ([elementName rangeOfString:@"ValidateSessionIdResult"].location !=
NSNotFound)
{
isValid = [inprocessString isEqualToString:@"true"];
isElementOfNote = YES;
}
if ([elementName rangeOfString:@"ValidateLoginResult"].location !=
NSNotFound)
{
isValid = [inprocessString isEqualToString:@"true"];
isElementOfNote = YES;
}
if ([elementName rangeOfString:@"iCRMUserId"].location != NSNotFound)
{
crmUserId = [[NSNumber alloc] initWithInteger:[inprocessString
integerValue]];
isElementOfNote = YES;
}
if (isElementOfNote)
{
NSLog(@"ending Element: %@", elementName);
// Clear the text and key
[inprocessString release];
inprocessString = nil;
}
}
// This method can get called multiple times for the
// text in a single element
- (void)parser:(NSXMLParser *)parser
foundCharacters:(NSString *)string
{
NSLog(@"found characters: %@", string);
[inprocessString appendString:string];
}
@end
This is more or less code that is in use, but I know that it hasn't been
profiled or really put under the microscope for performance or memory leaks,
but hopefully it will give you something you can work with.
The short version is that XML is a little painful on the iPhoneOS. So we
generate the Xml post in a string and then use the NSXMLParser on the back end
to quickly break down the results. A lot of the ideas and concepts here came
from looking at how other people tackled the problems, but in the end, this was
the solution I used. It works, but I do not know if it is necessarily the best
answer.
I apologize in advance for any formatting issues, this is composed on an iPad,
and well, I am still getting used to it :-).
Andy 'Dru' Satori
On Apr 9, 2010, at 11:00 AM, Joanna Carter
wrote:
> Hi folks
>
> Well, I've just spent the last few days, getting to grips with consuming a
> web service.
>
> I though I would try things out in an OS X app first, then move to the
> iPhone, which is the end target.
>
> So, I decided to use WSMakeStubs on the WSDL - it did a reasonable job, apart
> from one or two minot bugs and niggles. Eventually, I got a test app working
> to prove that I could read the service.
>
> Then I thought I would move the app to iPhone, only to discover that the
> classes generated by WSStubMaker would not compile and that I would have to
> find another way to create the stub classes for an iPhone app.
>
> Can I ask what is considered the best route to go?
>
> Joanna
>
> --
> Joanna Carter
> Carter Consulting
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com
>
> This email sent to d...@druware.com
>
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Delayed Autorelease
This is a really common problem for developers coming from other platforms. In the Windows world the only thing really analogous to retain/release is the COM addref concepts, and even those lack the equivalent of autorelease. The short version, in my experience, is when in doubt, manage the memory with retain and release pairs. Garbage collection is good, but can have unexpected behaviors that become tricky to debug. I know there are people that idol disagree, but between apple's leak finding tools, llvm's analysis tools and shark, it is often easier to hunt down a leak using old school retain/release methods than new school garbage collection. Sent from my iPad On Apr 8, 2010, at 11:09 AM, Steve Bird wrote: > > On Apr 8, 2010, at 10:36 AM, Patrick M. Rutkowski wrote: > >> Is it common in either Cocoa or UIKit to have an autorelease run >> happen only when the user does something? >> >> I'm in a situation where I believe the autorelease run is happening >> only when I push a bush or otherwise fiddled with a UI item; might >> that be the case, or am I confused? > > I don't know about pushing bushes, but in general the "autorelease run" is at > the end of an event loop, when your code has finished responding to an event, > and the system is about ready to look for another one. > >> Is there perhaps a way to have it logged to the console whenever an >> autorelease run happens? > > --- A log to the console on every event would swamp you in data, I think. > > > Steve Bird > Culverson Software - Elegant software that is a pleasure to use. > www.Culverson.com (toll free) 1-877-676-8175 > > > ___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/dru%40druware.com > > This email sent to d...@druware.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
