Wes and Nate,
> > Do we want to include on-the-fly gzipping (and ungzipping=20
> when we get
> > opening functionality)? I don't think this will have a=20
> major impact on the
> > sizes of generated files but it would be interesting to=20
> implement...=20
Actually it will have a major impact....
$ ls -al kardia.*
-rw-rw-r-- 1 centrall centrall 25692 Aug 21 10:35 kardia.app
-rw-rw-r-- 1 centrall centrall 3797 Aug 21 10:35 kardia.app.gz
-rw-rw-r-- 1 centrall centrall 42110 Aug 21 10:35 kardia.xml
-rw-rw-r-- 1 centrall centrall 4599 Aug 21 10:35 kardia.xml.gz
> I guess
> > another advantage would be for posting the XML to=20
> centrallix via the web.
As nate pointed out, it would be a PUT, not POST, but this would =
_really_ be cool... Especially once we can open from it too...
Of course, the other option is to impliment BDQS ;)
> Yeah, on the fly gzipping would be cool to have as an option at save=20
> time, and autodetected at open.
yeah, especially with 42k applications :)
> > Also, what is the URL to get the source of a displayed=20
> kardia app?
That would be:
http://server:port/kardia/kardia.app?ls__type=3Dtext%2fplain (or if =
there's a chance it could be gzipped, application%2foctet-stream might =
be more appropriate)
However, this wouldn't be too useful on a .app file (unless you write =
that converter into bojangles :), but would on a .xml one...
Jonathan
|
