On Thu, Oct 8, 2009 at 10:11, Ian Boston <i...@tfd.co.uk> wrote:
> 1. The URL space is part of the UI and "owned" by the User, UX Designer, UI
> developer.
> 2. Imposing a convention on that URL space for the affordances of the back
> end causes just the problem that you are concerned about. Now the UI
> developer needs to know the internals of how to structure those URLs to
> achieve scalability.
> ...
> BTW, a UI developer does not write Java code. They use the REST interfaces,
> they might write some py, esp or rb.
> ...
> On 1, our Users, UX Designers and UI developers are demanding URLs like
> /xxxx/yy where for all instances of yy, yy is unique, and yy might be on of
> 1-200K and in some instances I know of upto 4M (the 16G is an edge case but
> if I break out of the Higher Ed use case there are plenty of examples of
> URLs where yy is one of billions).   There are two solid examples /user/eid
> where eid is the institutional ID and /site/siteid where site ID the name of
> the Site, eg physics101.
> ...
> On 2. If we have to communicate how to structure the URL to UI developers
> for storage, then it hardly matters what the scheme is, we have to
> communicate it. An algorithm that says formatTime(now,"/{YYYY}/{MM}/{DD}/")
> is almost as simple as formatSha1(pathInfo,"/{01}/{23}/{45}/{67}") but I
> cant ask the UI developer to to do either. This is not to say that they
> might not decide to structure the URL in a semantic form, and I would
> encourage them to do so, but they always come back to the case where there
> is a user generated URL space that will have > 10K items at yy.

IMHO the content structure is a critical part of the system (at least
on the technical side), so I would involve a developer with knowledge
and experience about the "underlying" repository and content modeling
whenever a new URL space is created by some application. Or teach the
UI developers about content modeling and provide them with simple APIs
to avoid flat or hash-based hierarchies.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetsc...@day.com

Reply via email to