Re: [fossil-users] JSON/wiki: what info needs to be returned for...
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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] /json/dir output format?
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: something entirely different?
Which would be simplest to use from client code while still being flexible
enough for more complex cases?
:-?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] /json/dir output format?
On 09/19/11 13:19, Stephan Beal wrote:
#3: something entirely different?
:) I'm missing the recursive structure somewhat. Maybe it's just me. I like
recursion.
{ "name": "subdir1", "content": [ ], "type": "{x in
link,file,directory}" }
file content: empty (or ? )
link content: file link
dir content: file/dir/link content list
lends naturally to relative operations this way.
Why #3 rather than #1/2a/b ?:
I don't like #1 because it misses links, and includes (has to) the whole path.
I think (guess, believe, ...) that relative operations are more often than
absolute operations (display, move, annotate, search, ...)
I don't like #2a because of the abbreviations. It's json, not a single byte
unix encoding necessity or something we're talking about here.
I don't like #2b because of a mix of above reasons ;)
Of course that also encodes my personal taste of things, which definitely
plays a role in the rationale above and Your Mileage May Vary as they say (or
your taste :)
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] /json/dir output format?
On Mon, Sep 19, 2011 at 1:19 PM, Stephan Beal 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 are being listed, then I would prefer a recursive version of #1. My second preference would be a recursive version of #2a. Also, I would like an option for having symbolic links distinguished from ordinary file/directory entries. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] /json/dir output format?
On Mon, Sep 19, 2011 at 8:07 PM, Ron Wilson 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 option to the HTTP request) almost for free (in terms of effort needed to add it) and the sub-elements will be structured under their parent dir. This will allow us to selectively pull a specific dir (or sub-sub-dir), optionally including all subdirs. e.g. something like /json/dir?maxDepth=3 (default=0, no recursion). i suspect that having it recursive by default would unduly overload the server and many clients (think "mobile phones"). There's no reason we can't use different structures for file/dir/link, with the caveat that they have to have one property in common so that clients can tell what the rest of the structure should look like (e.g. type=... would do fine). @Martin: we're of course not restricted to single-letter flags. "file", "dir", and "link" (or "symlink") would be fine. "directory" seems a bit verbose, but i wouldn't argue against it on any grounds other than it's verbosity. Also, I would like an option for having symbolic links distinguished > from ordinary file/directory entries. > Good idea. That rules out #2b unless we want multiple flags (i'd prefer, but not strongly, to only have one flag, e.g. type="dir|file|link"). On a related note: i just committed /json/wiki/list, which simply returns an Array of page names. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Feature request: edit files via web interface
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 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: edit files via web interface
On Mon, Sep 19, 2011 at 9:48 PM, Marco Maggesi wrote: > 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 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.) Once that is in place (it won't be very soon, but it's planned) editing non-wiki (text) files like this could be added to the HTML interface without any significant changes in the core app (just a pretty page to wrap the JSON API calls in). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: edit files via web interface
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 people to build binary file capabilities later (e.g., canvas-based image editor or some completely-non-web-browser integration). Also, I wonder if stash commands could be manipulated to put together multi-file commits. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: edit files via web interface
On Mon, Sep 19, 2011 at 11:48 PM, Joshua Paine wrote: > 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 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 drops. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: edit files via web interface
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 drops. 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 another string if they don't understand base64 encoding. I'm not trying to tell you what you have to implement, but supporting base64 for sending and/or receiving binary data doesn't really add much to the complexity of the API or client requirements. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: edit files via web interface
> 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: ] dmitry added on 2011-01-20 14:01:59 UTC: Here are some thoughts on implementation. • Have "can edit on web" permission flag. • Have special per-user staging area for edits from web, which records modifications to files. • Once file(s) are edited, they're put into the user's staging area. • User can commit his staging area if he has commit permission. • Users without commit permissions, but with "can edit on web" permissions, can create tickets with modifications from their staging area or download their modifications as a patch. This won't work for anonymous or other "group" users. For those Fossil can have per-file editing without staging area. Also, not sure how to handle merges. -- Dmitry Chestnykh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: edit files via web interface
On Tue, Sep 20, 2011 at 12:26 AM, Joshua Paine wrote: > 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 another > string if they don't understand base64 encoding. > But they're then limited by what they can do with it. base64 is useless if you don't have a decoder. > I'm not trying to tell you what you have to implement, but supporting > base64 for sending and/or receiving binary data doesn't really add much to > the complexity of the API or client requirements. To the C side it's pretty easy, but adding any sort of encoding inherently limits the clients which can use it. There is no reference implementation of base64 for JS, for example (there are impls, though), and JS cannot natively deal with binary data (that's coming in v5 or whatever new version is coming soon). Storing binary bytes in a JS string provides undefined results. The primary clients (mine, at least) will be JS. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: edit files via web interface
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. To the C side it's pretty easy, but adding any sort of encoding inherently limits the clients which can use it. Well, unless you only use it for stuff that fossil treats as binary anyway, in which case no one's limited, because the alternative is not having access at all. and JS cannot natively deal with binary data (that's coming in v5 or whatever new version is coming soon). Standard javascript doesn't have this ability yet, but individual impl have relevant capabilities. E.g., privileged JS in XUL has access to files and can get base64 strings from them, and the canvas element has a toDataURL method that returns base64 encoded data plus a tiny amount of metadata. -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
