Thanks for your response, Stephan.
Amen! IMO the UI "should" be done using mostly JS (e.g. via jQuery
or similar), however, that would break "lesser" browsers, and IMO
they are an important (or at least not minimal) consideration for
fossil. So... as much as i'd like a "real" UI (e.g. google mail),
i'd hate to see fossil move that direction.
The likes of Gmail and many other highly AJAX driven websites have
essentially forced people to move and upgrade their browsers to the
most recent versions essentially making a lot of web developers lazy
in supporting backwards compatibility with browser environments that
are devoid of options they feel should be mandatory. This is not to
say this is the direction I feel fossil should go. I think the design
of Fossil's UI should completely separate markup, style sheet and
javascript so neither is inline to the other, so that within the C
code only well-formatted HTML needs to be built. My suggestion for
event driven Javascript is not an attempt to restrict browser usage to
the most recent browsers as many older browsers do support this
method, it is however partly because I don't think markup like '<a
onmouseover="" onmouseout="" href="">' (timeline.c line 58-59) is
good practice, and because the removal of inline Javascript would also
help in handling with page degradation.
Ideally (and longer-term), i think we could/should implement JSON
interfaces into/out of fossil, so that we could write AJAX apps on
top of fossil. With that in place, multiple WUIs could be created
using one's own favourite JavaScript library (*cough*jquery*cough*).
i've been looking at C libs lately for adding some JSON output
support to fossil (e.g. timeline/commits data), but the open source
JSON-generation C libs i've looked at "just don't do it for me," and
i haven't yet settled on one (i don't want to implement one if i can
avoid it, though it might be useful to implement a custom one on top
of the fossil blob data type, to take advantage of the memory
management).
Personally I'd be more inclined to use pure XML over JSON to give
greater flexibility, as much as I detest XML as a format, it seems
every programming language out there I've ever dealt with has some
sort of XML library. Hey, even Applescript has ways of parsing it.
2) Solving future Internationalisation (i18n) and Localisation
(l13n) issues
Porting fossil to be "i18n-ready" would be a major undertaking.
Without a doubt it will be a huge undertaking, and it will completely
re-arrange a lot of the code structure. It seems DVCS's themselves are
not very well supported towards internationalisation, however bug/
project management tools (Trac, RT, Bugzilla) are at varying levels,
so it's suffice to say that at present there is demand for it, at
least for the UI. I feel it is a case of "if you build it they will
come", as there is more non- English speakers on the internet than
native English speakers. Making the changes now before the code base
gets bigger will make it less painful.
Question: Would it be feasible to implement a very basic search
function of documents in the wiki?
i think the biggest problem there is that the wiki is stored as
compressed diffs. To do a real search, one would have to decompress
every version of every page and perform the search on it. You could
limit it to only the latest versions, but it's still got to
reconstruct the page before it can perform the search. It could
stuff that into an sqlite3 :memory: (or temp) db and perform the
actual search from there.
Sounds like it would be difficult. I am by no means an expert on
search engines, but would it be feasible that when a wiki document is
committed that it is quickly indexed and then the index stored in
database instead?
~ James
Lasgo Chrysalis Limited. Registered in England & Wales No. 1380166.
Part of the Chrysalis Plc.
Registered office: The Chrysalis Building, Bramley Road, London W10 6SP
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
