State of iMedia

[joerg.j...@mac.com]

Hi everyone,

iMedia 3.0 (supports sandboxing and XPC services) has come a long way and is now used in two major apps (FotoMagico and my client's app).

I have just merged Mike's latest pull request from iMedia 2.5 with the 3.0 development branch into branch karelia-master for testing and will merge it into development in about a week. Doing so I had to resolve a lot of conflicts (like similar fixes on both sides to appease static analyzer) and some changes to iMedia 2.5 that took a strange route into iMedia 3.0 probably due to renamed files. Ultimately, this was a lot of work and I was not always sure that I picked the right code chunks in any situation.

In short: I would rather prefer to phase out 2.5 pull requests and to have all parties reunited in one repository and one master branch.

What is your plan of adopting 3.0?

Best regards, Jörg.

[Tyler M]

I'd like to toss my homegrown iPhoto integration library and adopt iMedia rather than hack mine to add sandboxing support.  Which repo & branch would you suggest one adopt?

I don't see any tags that indicate which is the stable version used in FotoMagico & the client app that you speak of.  master appears to be a month old,  development sounds like a branch for active development, not where release ready code would be (unless there was a tag, but I'm not seeing one), and karelia-master seems like it's also an active development branch (just got a large tricky sounding merge and you talk about merging it down to development as if it's less stable than development)? 

Thank you,

Tyler

[Dan Wood]

So right now we are at a tricky crossroads.  Hopefully we can figure things out and get people on one code base.

The 3.0 branch work that Jörg and Peter have been working on have some big architectural improvements.  However, some us feel that the API itself in the 3.0 branch is not really ready for "prime time."  If people are going to have to switch to a new API to start using 3.0, I think that we should do as much as we can to make sure that the API is bulletproof and simple, exposing only what's needed, and exposing none of the internals of how the code is implemented.

The 2.5 (master) branch, which works fine in the Sandbox by putting entitlements in the app, rather than the processes, is not much better as far as a simplified API; don't get me wrong.  But if we are going to start using a new API, let's get that new API ready before we start trying to get people to adopt it.

For Tyler, starting out anew, it's probably better to go with the 3.0 codebase, but digging into it now will probably be more difficult than it would be to wait until the API is cleaned up.

Maybe we could come up with a conference skype call, where we could walk through the API that we have in 3.0 right now, and what we could do to clean it up.  I know that Mike here at Karelia definitely had some issues that he wanted to point out.

Thanks,

Dan

[Tyler M]

Thank you for this perspective Dan.

Would you be willing to share the in-app entitlements that were sufficient to get 2.5 through the MAS approval process?  The version of Sandvox that is downloadable from the Karelia site is not running as a sandboxed app in 10.7.5 and the entitlements therein don't seem sufficient to enable it to function in a sandboxed environment without the user having to choose, for example, the iPhotoLibrary and every folder containing images (e.g., network volumes), unless I'm misunderstanding something (quite possible).

thank you,

Tyler

[Mike Abdullah]

On 7 Nov 2012, at 19:47, Tyler M <hai...@gmail.com> wrote:

> Thank you for this perspective Dan.
>
> Would you be willing to share the in-app entitlements that were sufficient to get 2.5 through the MAS approval process? The version of Sandvox that is downloadable from the Karelia site is not running as a sandboxed app in 10.7.5 and the entitlements therein don't seem sufficient to enable it to function in a sandboxed environment without the user having to choose, for example, the iPhotoLibrary and every folder containing images (e.g., network volumes), unless I'm misunderstanding something (quite possible).

Hi Tyler,

Scroll down to the README file at:
https://github.com/karelia/iMedia

Let me know if there's any more details that the docs don't provide.

The current version of Sandvox on the app store is 2.7.1, and is sandboxed. It's only been live a few days; perhaps you still have 2.6.7?

[Tyler M]

Thanks Mike. The Readme says to search headers for SANDBOX, so I'll do that and see what I come up with.

I have Sandvox version 2.7.1 but *not* from MAS.  "The version of Sandvox that is downloadable from the Karelia site" is what I said above and what I just downloaded today to look at the entitlements.

Non-MAS is maybe not running sandboxed by design and so doesn't seem to have the sandboxed entitlements sufficient to use iMedia functionality.  Little odd because it does have some sandbox entitlements and an entitlement file that says sandboxing true, but in 10.7.5 at least Activity monitor is showing it not running sandboxed ( https://dl.dropbox.com/u/1467270/Screen%20Shot%202012-11-07%20at%2011.37.36%20AM.png ).

Thanks,

Tyler

[Mike Abdullah]

Ah, I can't read it seems :)

Our regular build is not sandboxed, although it carries some artefacts of that as part of our build system. We're using all the entitlements as described in iMedia's code.

[joerg.j...@mac.com]

The 3.0 branch work that Jörg and Peter have been working on have some big architectural improvements.

Let me also point out what additional major features 3.0 serves:

- you can now customize the appearance of the iMedia browser through appearance objects eliminating the need to tweak the framework for that matter. The appearance API already employs public and framework-private headers. Set CUSTOM_USER_INTERFACE to 1 in IMBTestAppDelegate to try it out.

- the framework now has the notion of "non-entitled" and "non-available" resources (e.g. due to unmounted drives). It handles these circumstances gracefully and gives the user clear indication on what state a resource is in (through different clickable badges at nodes and media objects

- you can build your app sandboxed (which will employ XPC services for resource fetching by default) or non-sandboxed (which will employ GCD for resource fetching) without changing a single line of code. You may also choose to run your app sandboxed employing GCD instead of XPC services but you will of course lose crash protection for your main app regarding the code that is normally executed in XPC services. You can run your app on 10.6 without any change.

However, some us feel that the API itself in the 3.0 branch is not really ready for "prime time."  If people are going to have to switch to a new API to start using 3.0, I think that we should do as much as we can to make sure that the API is bulletproof and simple, exposing only what's needed, and exposing none of the internals of how the code is implemented.

It is definitely worthwhile to differentiate between public and private API. And I plead for reunified core development should drive encapsulation instead of encapsulation should drive reunified core development.

Best regards, Jörg.

[joerg.j...@mac.com]

Tyler, you are right, we should fast-forward 3.0 master branch to current state of development (which is what apps already built upon).

Regards, Jörg.

[Tyler M]

thanks, that helps.

[Peter Baumgartner]

Hi,

Let me add my $0.02 to the dicussion:

The impression that iMedia3 in "not ready for prime time" is IMHO not correct. It is way more ready than 2.x ever was. It contains fewer bugs, and it has solutions for sandboxed applications that will not be possible with a patched version of 2.x. Jörg already mentioned some of those.

iMedia3 is already in use by two apps (FotoMagico 4 and ifolor Designer). While the majority of bugs/crashes in FotoMagico 3.x (which used iMedia2.5) were iMedia related, this has dropped to almost zero in FotoMagico 4 (which now uses iMedia3). So from personal experience I can only encourage developers to migrate from iMedia2 to iMedia3. Obviously, if you choose not to sandbox you app, then there is little incentive to migrate.

As for cleaning up the API we should talk about that, but always keep in mind the impact on deployed apps. Simplifying the API should not make customization impossible, as some apps require that. A conference in the near future is probably called for.

Cheers,

Peter

[joerg.j...@mac.com]

Master branch of iMedia 3.0 now contains latest stable version.

Regards, Jörg.

[Daniel Jalkut]

With iMedia 1.5 the majority of crashes I continue to see have to do with hangs in parsing Lightroom databases, or crashes vaguely connected to IKImageBrowserView. I think at least the Lightroom issues might be mitigated by the XPC approach in iMedia 3? Though I'm not sure what happens if an XPC process itself just hangs up for too long. Does it get killed?

I would also strongly encourage folks to consider customization when considering the API. The compromise in 2.5 of being able to subclass some key classes and/or provide alternate XIB to existing classes has been very useful for me in coercing iMedia to fit the context of my existing app media window.

Daniel

[joerg.j...@mac.com]

Not sure what you mean by "hang". If the Lightroom parser crashes its XPC service it is gone like any other process. It will be restarted by the OS on next issued request to it. This is especially helpful when bugs non-deterministically crash the service (like multi-threading issues). And of course it is helpful in any case that you can just keep on working in your app using other resources if the Lightroom library won't work.

Jörg.

[Daniel Jalkut]

Hi Jörg - I mean "hang" in the conventional sense as used by Apple when a process stops yielding to the thread (literally get stuck processing something interminably).

Literally: what happens to an app when an XPC-backed parser has "while (1) {}" compiled into it?

Daniel

[joerg.j...@mac.com]

The app won't hang. Requests to XPC services are asynchronous and the reply handler in the app for that request will never be called. The XPC service will even still accept subsequential requests since it spawns a new thread for each request. If a hang drains CPU cores it's another issue.

Jörg.

[Daniel Jalkut]

Thanks, definitely sounds like a win for reliability. I'm looking forward to switching to 3.0 as soon as I get a chance. I would definitely prefer to see these changes moved back into the main repository assuming concerns about API complexity can be sorted out.

Daniel

[joerg.j...@mac.com]

Don't know whether it will be killed for something taking too long. Wouldn't expect it but have not had such circumstance yet on my machine.

Jörg.

Am 09.11.2012 um 16:36 schrieb Daniel Jalkut <jal...@red-sweater.com>:

[Mike Abdullah]

On 9 Nov 2012, at 16:04, joerg.j...@mac.com wrote:

> The app won't hang. Requests to XPC services are asynchronous and the reply handler in the app for that request will never be called. The XPC service will even still accept subsequential requests since it spawns a new thread for each request. If a hang drains CPU cores it's another issue.

Does that mean you've stopped trying to persuade XPC to behave syncronously then? That was my main worry about the new design.

[Jörg Jacobsen]

Synchronously? No, we are employing standard XPC behaviour.

Jörg.

[Mike Abdullah]

On 9 Nov 2012, at 18:43, Jörg Jacobsen <joerg.j...@mac.com> wrote:

> Synchronously? No, we are employing standard XPC behaviour.

Excellent. When XPC was first being set up, I recall some work being done to make it behave synchronously; glad that's no longer the case.

[joerg.j...@mac.com]

I agree.

BTW, we are currently preparing a little guide to adapting apps to iMedia 3.0 based on the experiences made migrating a third app to 3.0.

Regards, Jörg.