Why not just 'attach' a url to a notice as you would attach an image
to an email? then length is not an issue. If you don't mess with the
message content and just add a char to specify the links in order
surely this is achievable?
i.e.
"This is a notice with an interesting #link. Ooo look, this #link
is useful too. I want to #tag this notice also."
1. http://link.one/message-url/is-very-long.html
2. http://you.can/cgi-bin/also.cgi?have=lots%20of%20special%characters
3. http://statusnet.installation/tags/tag
Your could hide the link information from the timeline and if people
want to see it they can click a "show links" button.
IMHO this has always been a failing of microbloging services, url
shortening is very unintuative/confising. Url's are packed with good
information, they should not be replaced with "http://ur1.ca/106o";.
Not mentioning that using services like ur1.ca create a single point
of failure.... the anti web :)
Many respected people on the web have raised this argument.
Just a thought.
Paul
On 22 Sep 2009, at 09:23, Jan H Wildeboer wrote:
Sarven Capadisli wrote:
On Mon, 2009-09-21 at 22:52 -0400, Craig Andrews wrote:
Right now, links in notices are very opaque - users really have no
idea
where they go when they click on them. For example, in this notice:
<p class="entry-content">Testing! <a href="http://ur1.ca/106o";
rel="external">http://ur1.ca/106o</a></p>
I must have overlooked this change because I remember we had <a
href="shortURL" title="longURL">shortURL</a> implemented.
This whole topic raises some interesting questions, which I would like
to jot down just for sake of completeness.
Q: What is a short URL? I guess this needs a list of "trusted"
shortening services - maybe plugins? Esp. with bit.ly you can have
personal accounts to help in tracking etc.
A: Specific metrics per service should be configurable somehow.
Q: Could this become a potential DoS vector? Imagine a flood of posts
with short URLs pointing to a shortening service that is either slow
or
unresponsive - could this fill up the statusNet system and lead to
potential harm?
A: We should have timeouts, max entries etc. per system/service to
avoid
congestion causing DoS scenarios. Maybe also dynamic - so say that
when
X queries to bit.ly take > 2s each, throttle it down and just show the
short URL.
Q: Is it safe to cache the results of the long URL? Some shortening
services might re-use the UUIDs they generate, so maybe have a TTL
setting per service?
A: Find out the TTL per service and make it configurable.
Just a braindump, ignore at your own will ;-)
Jan
--
Jan H Wildeboer |
EMEA Open Source Affairs | Office: +49 (0)89 205071-207
Red Hat GmbH | Mobile: +49 (0)174 33 23 249
Technopark II, Haus C | Fax: +49 (0)89 205071-111
Werner-von-Siemens-Ring 11 -15 |
85630 Grasbrunn |
_____________________________________________________________________
Reg. Adresse: Red Hat GmbH,
Technopark II, Haus C, Werner-von-Siemens-Ring 11 -15
85630 Grasbrunn, Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Charles Cachera
_____________________________________________________________________
GPG Key: 3AC3C8AB
Fingerprint: 3D1E C4E0 DD67 E16D E47A 9564 A72F 5C39 3AC3 C8AB
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
