I had intended to build exactly that years ago, but never got around to it... mostly because it's hard to do client side and I didn't want that feature to be dependent on some server-side script.
My thinking was that we'd keep packed versions of every module (so that we could continue to use the Java based packer, instead of implementing a JavaScript version)[1] and some client-side could could XHR them all down and concatenate them in the correct order, but the problem is allowing the user to actually download that text. Using the pasteboard would work I guess, but that's not a nice solution. I suppose we could set something up where the client just does a POST to some URL (maybe an app engine service or something) and the server simply echos it back with a Content-Disposition header that forces download. [1] But maybe it would be reasonable to write an entirely JS based packer with Narcissus http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any other projects like this that I'm not aware of? -bob On Mon, Oct 13, 2008 at 4:47 AM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > Seeing that this wasn't just an omission, I won't change it for the 1.4 > version. > > For version 1.5 I think we should consider having a nice little > download web page where you can customize your packed version of > MochiKit. I created a little dummy UI to show what I mean: > > http://www.percederberg.net/mochikit/pack.html > > If we plunge forward and start adding more extension modules (as > suggested here before), I think such a UI would be important to keep > all users happy. > > Cheers, > > /Per > > On Wed, Oct 8, 2008 at 3:44 PM, Arnar Birgisson <[EMAIL PROTECTED]> wrote: >> Hi Per, >> >> On Wed, Oct 8, 2008 at 15:38, Per Cederberg <[EMAIL PROTECTED]> wrote: >>> The packed version of MochiKit still doesn't include the modules >>> DragAndDrop and Sortable. I found a previous discussion of that in >>> this thread: >>> >>> http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99 >>> >>> None of the two modules have been much modified lately, so perhaps >>> they are now stable? Otherwise, I think we should make the docs >>> clearer regarding their status and how to use them. >> >> Including them is fine with me, but for my own purposes I don't use >> that.. since for me MochiKit serves purely as a utility library rather >> than one of UI elements. I suspect there are others in a similar >> situation. >> >> What we really should do, and it should not be too hard, is make >> several packed versions. Basically for every module we'd provide a >> "dependency-closed" packed version - i.e. one that includes that >> module and all of its dependencies. Modifying the "packed" script to >> perform this should be doable. >> >> If people don't like the idea of so many packed versions, perhaps we >> could decide on two or three "feature-sets" and provide packed >> versions of these. I know MochiKit is not that big, and download time >> is not really the issue - but bandwidth can be an issue for the host. >> >> cheers, >> Arnar >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
