[Sparkle] A Question of Enclosures

[Adam Radestock]

First of all, thank you all for your input - it was very insightful.:-)

On 4 Apr 2008, at 3:04 am, Rob Napier wrote:
> Here are some thoughts on what the ideal app should do:
>
> * I should be able to drop an App bundle on it (or open an App  
> bundle from File) and that should pull everything into a form along  
> with reasonable guesses on what I'd like to do (prior choices should  
> be saved in defaults to reuse them).
>
> * I should then modify that form based on what I really want.

No problem. :-) That's the conclusion I came to also.

>
> * "What I want" should include "build dmg" or "build zip" (as well  
> as manually setting the version, etc). Unfortunately, building DMGs  
> really means building custom DMGs because that's what everyone  
> wants. And building a system to do that in a really general and  
> reliable and programmatic way has been hard in my attempts for  
> Pandoraboy.

Don't forget that all of the DMGs that SparkleCaster downloads are  
internet-enabled, if not by the developer, then by Sparkle when it  
receives them. That is to say that the DMGs are run through the hdutil  
command line utility and set as internet-enabled–so they dump their  
contents and trash themselves.
So I can't imagine people wanting to put extra stuff (like readme  
files, etc.) in this kind of package, any more than they would in a  
zip. In the case of Sparkle, DMG is just a way of archiving the data  
between developer and client app; the user never sees this info.

On 4 Apr 2008, at 6:31 pm, Jerry Krinock wrote:
> I think that the biggest challenge you have with SparkleCaster is  
> going to be to make it simple enough, yet flexible enough.   
> Independent developers especially are, by definition, independent,  
> and tend to adamant about doing things their own way.  Now, I would  
> have been very happy to have such an app before I developed my own  
> "shipping" script, but since I've already done that now, it would  
> take alot of plusses for me to consider something like  
> SparkleCaster.  My script does many silly things that only I would  
> want.
>
> I haven't read read much of this thread, so I'm not sure what you're  
> doing, but I would advise you to target new developers who need to  
> publish a simple app quickly and don't want to take the time to  
> learn Sparkle, packaging, and scripting shipments.  Some hooks for  
> more advanced developers to hang in their own scripts might give  
> SparkleCaster a more lasting appeal, but of course that could wait  
> for your version 2.0.


I already have plans to include a command line utility which will have  
the same functionality that the GUI tool does. This will enable the  
'build script savvy' developer to include SparkleCaster in their build  
scripts.

For example, you could have a build script that digitally signs your  
code (check out the Leopard dev docs for this - worth reading up on),  
then calls something like:

sparklecaster -c [path to your project's SparkleCaster document] -a  
[path to your build product] -n [any release notes (from a text file  
or a URL) -b [ftp server address] -u [username] -p password

This should be in version 1.0, as I just have to hook the calls into  
my existing code. (Thanks to Josef W. Wankerl for his work on this).

On 4 Apr 2008, at 8:26 am, Andy Matuschak wrote:
>> What would be the best practice for dealing with the actual
>> enclosures?
>
> I had thought for a while that it'd make sense to keep around the
> enclosures and have SparkleCaster keep track of them, but now, I can't
> think of a case in which that'd be useful, so probably don't bother.

On 4 Apr 2008, at 3:04 am, Rob Napier wrote:
> * I don't think I would cache the enclosures if they're going to be  
> put into the package. The only valuable thing I could see there was  
> saving the last one, just to have a template to work off of (but a  
> real template might be better here).

I agree. So I'll keep a reference to the (dmg'd/zip'd) package until  
the file is successfully uploaded, then forget about it.

Thanks again for all your input and support.

Kind Regards,

Adam Radestock
Glass Monkey Software
www.glassmonkey.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andymatuschak.org/pipermail/sparkle-andymatuschak.org/attachments/20080405/e4be1899/attachment.htm