> An URL would be enough. Most bugtrackers are web based anyway. And those
> which aren't can install a new URL scheme to spawn the required
application.
There might be reasons to use a local program/script instead of only
supporting a URL. It's a small difference from TSVN's perspective (the
local exe/script is a simpler case than a HTTP URL). But either way,
local exe/script support can be added later (like you said, via a file:///
URL).
> More than a normal "GET" would be too much. After all, we're talking
> about Subversion clients here, not webbrowsers!
So long as the params don't exceed GET's length limit (ie. a URL), that's
fine. Otherwise, POST or custom headers will be needed.
> And here the problems start:
> XML isn't something you can do without an external library. Even though
> there are free XML libs available, they're all quite big - and
> increasing the download size of a Subversion client by 150% just for
> that is IMHO just too much!
The only C++ XML library I have substantial experience with is Xerces
(http://xml.apache.org/). Xerces is <2MB uncompressed, <600KB zip-
compressed. Both numbers are a fraction of TSVN's download size, _not_
larger. Out of curiosity, which C++ XML parsers have you seen that are
~6MB in size?
I would be surprised if there weren't XML parsers that were smaller than
Xerces. You don't need all the features of Xerces.
> For example, the XML schema could define a full list of possible
> output, but perhaps the issue ID # is the only required piece.
> So if an issue tracker can return other info (project, component,
> subject, etc), it's up to client to display it.
> You have to define _exactly_ what the client has to show. And don't make
> this expandable - you'll just end up with a security risk (buffer
> overflows, ...) if a client can't be absolutely sure on how the data has
> to look like.
The XML schema defines the output format precisely. One of
the nice features of XML (and schema in particular) is that the XML
parser does the validation for you--including size if desired. Secondly,
the XML parser handles capturing all the data from the file dynamically--
it can handle arbitrary sizes. Where would a buffer overflow come from?
Regarding the client, I meant that each client can display individual
pieces of the output.
For example, you can see if a "project" attribute was specified, and if
so, display it. Likewise for any other attribute.
So TSVN may only be interested in the "id", "subject" and "url" values.
And it will display whichever of those are available.
Another client may want to display all available info to the user, so
it will dynamically populate a report list (create the columns and
populate the rows).
> Now what's the difference of spawning a separate dialog to just open a
> webbrowser with a specific URL?
The difference is saving the user from having to manually navigate the
issue tracker to find his/her issues, and then manually copy each issue
ID to TSVN individually.
This new system will allow the user to multi-select issues from a list
and move on.
> That's not possible: the username isn't known to the Subversion clients
> until you commit. So where would you get that username from?
I was afraid of that.
How does TSVN handle saved credentials? Does TSVN store them or SVN?
If TSVN has access to this storage area, maybe get it there.
Otherwise, perhaps store the user name in a local configuration and use
it.
> What would that be good for? I mean every developer can have a different
> path to his/her working copy. And not all of them will have checked out
> from e.g. /trunk/ but maybe a subfolder, so even relative paths won't
> help here.
I tend to agree; this data was out of left field. I was thinking some
script may want to search for known values (like project, component, etc)
to try and deduce certain values. Disregard.
> c) Possibly support other bugtraq: properties which can be
> fed as arguments.
> ex: bugtraq:issueproject, bugtraq:issuecomponent, etc
> d) Optionally support credentials for the issue tracker.
> And that's exactly why this same feature request was rejected the last
> time: you don't know where this should end. Everyone will have a
> different request which would have to be added:
> username/date/daterange/issuetracker-component/project/subproject/
So? It's easy to allow for custom arguments.
Since the "system" is comprised of a client-server-issue tracker
combination, the user can define arguments that make sense to his/her
application. He defines the properties, he sets the values, he sets
up the program to expect & use these arguments when delivering the
issue list.
Unless I'm missing something, the only obstacle here is getting the user's
SVN user name. And even that can be solved relatively easily.
Even in the worst case scenario--the user can't get all arguments to the
program for generating the list--so what? I think it will still be
quicker and more convenient to search through a slightly-constrained list
than having to manually do all the leg work.
Regards,
Nick G.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 10 20:04:32 2005