On 3/31/2010 02:57, Thomas Mullaly wrote:
Hi, my name is Thomas Mullaly and I am a undergraduate in the Computer
Science department at Kent State University and I would very much like
to participate in this years GSoC. I saw under your project ideas page
that the IUri API still needs implemented and I thought that this
would be a good project for me, but, before I submit a proposal on it
I have a few questions about the project itself.
Hi, Thomas, and welcome.
Firstly, on the project page it says that the main goal is to have the
IUri interface and CreateUri function implemented, but, on MSDN they
also have functions and interfaces for creating/manipulating
IUriBuilder's and I was wondering if these were also part of the
project goals. If not can they be or would this be to ambitious to
have finished by the end of the summer.
Right, a complete IUri with corresponding tests will be enough for a
summer project I think. After a brief look at IUriBuilder I think it
doesn't depend on a IUri implementation details so much. For IUriBuilder
one way I see is to track changed properties and store only new data,
using unchanged properties from supplied IUri, but this needs some tests
(does it keep reference for IUri for example or not).
Secondly (more of a design question), I see that the Uri structure and
functions are already stubbed out in the "dlls/urlmon/uri.c" file and
I was thinking for my implementation I would add another BSTR* member
to the Uri struct, which will point to the encoded version of the URI
(which will be generated during the CreateUri() call). Since most of
the functions that interact with the IUri return components of the URI
(e.g. scheme, host, query, etc.) I was thinking about adding more data
members to the Uri struct which store the location in the encoded Uri
string where each component exists (or -1 if it does not exist) and by
doing this the runtimes of the IUri functions will be reduced since
the function will already know where to look inside the encoded string
for the component it needs. A drawback to this design is that each Uri
struct will be bloated with a decent amount of ints which may or may
not be used depending on the type of the URI that the IUri represents.
The second approach I was thinking of is to not store any locations
inside the Uri struct and to compute them on the fly every time the
IUri is queried for one of its components, this would result in a
smaller memory footprint of the Uri structure but will increase the
runtimes of all the functions that access the URI. I was wondering if
anyone might have suggestions for which way they think might be better.
You could use dynamic array for that or a list with a Uri_PROPERTY value
as a key for example and a data as an offset and length. Another way is
to compute each property offset only when it's requested and store it.
An obvious bad case for that is a long uri. So probably one pass
property computation while building IUri instance is not bad.
Waiting for Jacek comments.
Any input will be greatly appreciated!
-Thomas Mullaly
