On 09/17/11 08:35, Richard Hipp wrote:
(Aside: Should we create a new fossil-dev mailing list for this kind of
thing, and preserve fossil-user for use by people who just want to use
Fossil and don't really care what is happening behind the scenes?)
Yes please :)
-Martin
Hi, all!
Which data format would you prefer to see in the up-coming /json/dir output:
#1:
{ subdirs:[ list, of, subdirs],
files: [list, of, files ]
}
#2a:
[ {name:subdir1, type:d},
{name:file1.txt, type:f}
...
]
#2b:
[ {name:subdir1, isDir:true},
{name:file1.txt}
...
]
#3:
On Mon, Sep 19, 2011 at 1:19 PM, Stephan Beal sgb...@googlemail.com wrote:
Hi, all!
Which data format would you prefer to see in the up-coming /json/dir output:
If outputing the content of a single directory, then my first
preference is #1. My second preference is #2a.
If multiple directories
On Mon, Sep 19, 2011 at 8:07 PM, Ron Wilson ronw.m...@gmail.com wrote:
If multiple directories are being listed, then I would prefer a
recursive version of #1. My second preference would be a recursive
version of #2a.
Once we decide on a format for one entry, recursion will come (as an
Hello,
often I would find very useful to edit versioned files trough the web interface.
Would you consider to add such a feature?
Thanks,
M.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
On Mon, Sep 19, 2011 at 9:48 PM, Marco Maggesi marco.magg...@gmail.comwrote:
often I would find very useful to edit versioned files trough the web
interface.
Would you consider to add such a feature?
That's an oft-requested (maybe the most-requested?) feature, actually. One
of the eventual
On 9/19/2011 3:57 PM, Stephan Beal wrote:
One of the eventual planned features of the up-coming JSON API
would be performing a commit. (This can't work nicely with binary data,
but that's a limitation we can live with.)
If you support base64 encoding, then it leaves open the possibility for
On Mon, Sep 19, 2011 at 11:48 PM, Joshua Paine jos...@letterblock.comwrote:
If you support base64 encoding, then it leaves open the possibility for
people to build binary file capabilities later (e.g., canvas-based image
editor or some completely-non-web-browser integration).
i'd like to (at
On 9/19/2011 5:54 PM, Stephan Beal wrote:
i'd like to (at least initially) not consider binary data, nor any
features which require that a given client implement (correctly) any
given decoding algorithm other than JSON. Any time any algo is added to
the client-side interface, the portability
often I would find very useful to edit versioned files trough the web
interface.
Would you consider to add such a feature?
Some thoughts to consider about implementation are in this ticket:
http://www.fossil-scm.org/index.html/tktview?name=ad98e8f665
[ copying here for discussion: ]
On Tue, Sep 20, 2011 at 12:26 AM, Joshua Paine jos...@letterblock.comwrote:
base64 encoding turns binary data into an ASCII-safe (and hence UTF8-safe)
string, so it could be used to prepare binary data for transmission as a
JSON value of string type. Clients could safely treat it as just
Last I'll say on the subject, since this is your code after all.
On 9/19/2011 7:15 PM, Stephan Beal wrote:
But they're then limited by what they can do with it. base64 is useless
if you don't have a decoder.
But they're not any *more* limited than they are if you don't support
binary at all.
12 matches
Mail list logo
