Feature request: Same page, different URL, highlights kept - 125 views
started by Roar Skullestad on 30 Oct 08
started by Roar Skullestad on 30 Oct 08
started by Roar Skullestad on 30 Oct 08
started by Roar Skullestad on 30 Oct 08
Technically, the considerations are probably many and varied.
http://groups.diigo.com/Diigo_HQ/forum/topic/diigo-approach-to-cname-type-dns-records-a-thought-for-the-distant-future-8563 focuses on a CNAME aspect.
Both
http://www.diigo.com/annotated/11051a3263d23479b7145351cc0b569e
and
http://www.diigo.com/annotated/f5a8bee57c6a5da398c0249f168395e9 lead to representations of shared/similar data but (at a glance) I couldn't find any obvious CNAME relationship (for want of a better expression) between the www.openoffice.org and qa.openoffice.org domains.
Et cetera.
> or register URL variants for an already bookmarked URL
Amongst my small/annoying stockpile of thoughts to be kept quiet, pending a suitable Diigo brainstorm, I had:
* site manager-defined 'URL synonyms' (for want of a better expression).
I might paraphrase Roar's suggestion above as:
* user-defined URL synonyms.
(Am I on track? Roar, please correct me if I'm wrong.)
Incidentally, some comparable discussion at http://groups.diigo.com/Diigo_HQ/forum/topic/next-phase-diigo-the-future-7336#9 and thereabouts.
However: synonymity may be not as easy to achieve as we wish.
Google Groups are (to me) the prime example of myriad URLs that may apply to a message, or group of messages. In the Google Groups situation I tend to annotate the URL for a single message, with as concise a URL as possible, and without the locale-specific part of the URL, and without ... etc.! YMMV.
For manager-defined variants: cross reference http://groups.diigo.com/Diigo_HQ/forum/topic/8974
> register URL variants for an already bookmarked URL
The suggestion of user-defined variants remains open.
For both scenarios: http://groups.diigo.com/Diigo_HQ/forum/topic/8930 is a collection of references to topics that state or discuss the URL-specific nature of bookmarks and annotations.
The most slick solution would be that diigo automatically detected URL "synonyms" (by using domain and a hash for part of the content as "key" for instance). Then, after annotating a page, the annotations would show up whatever synonym URL I used, without me having to register anything. Optionally diigo could present a "Remove synonym" link on the specific "synonym page" or on the bookmarks page.
- Roar
The whole backend system is URL based and it will bring much complexity and load to implement this feature. For example, it costs more computation power for EVERY page you visit to decide whether there are some synonym URLs. Suppose there are M users, every user visits N page a day, ever page costs extra e% computation power, It will add M*N*e% extra load to the system per day.
Understood, completely. Just kicking the ball around :)
> > > * site manager-defined 'URL synonyms'
> > > (for want of a better expression).
> > > * user-defined URL synonyms.
> > automatically detected URL "synonyms" (by using domain and a hash
> > for part of the content as "key" for instance). Then, after
> > annotating a page, the annotations would show up whatever synonym
> > URL I used, without me having to register anything. Optionally
> > diigo could present a "Remove synonym" link on the specific
> > "synonym page" or on the bookmarks page.
> The whole backend system is URL based and it will bring much
> complexity and load to implement this feature
Parallel to the notion of editable URLs
( http://groups.diigo.com/Diigo_HQ/forum/topic/99#6 )
I'd like to resurrect the notion, debatably more useful, of synonyms or aliases - so that annotations related to one URL can be echoed against at least one other URL.
Example
http://dev.plone.org/plone/ticket/9249 and
http://dev.plone.org/old/plone/ticket/9249 are new and old public views of an item within the Trac for Plone.
For greatest public visibility, in the interest of openness:
I apply my highlights to a public version.
For personal sanity:
I choose the version that has a traditional Trac appearance.
For actual work on Plone:
in this type of Trac installation I must use https instead of http,
https://dev.plone.org/plone/ticket/9249 or
https://dev.plone.org/old/plone/ticket/9249.
Summary
In three of four views of essentially identical content, I lose my annotations.
In this case I would require:
* three aliases to a single URL
* more broadly, aliases to apply site-wide i.e.
http://dev.plone.org/plone/ is primary,
http://dev.plone.org/old/plone/ https://dev.plone.org/plone/ and https://dev.plone.org/old/plone/ are synonymous for Diigo purposes.
Cost:benefit ratio
I appreciate that these use cases may be niche, but the overall value will be great.
Not a priority, just food for thought for the future.
Thanks
Graham
http://groups.diigo.com/group/Diigo_HQ/content/552219#1 and
http://groups.diigo.com/group/Diigo_HQ/content/552219#2 as separate
(resolving issues such as http://groups.diigo.com/group/Diigo_HQ/content/548034 and http://groups.diigo.com/group/Diigo_HQ/content/587239),
so the most careful users of Diigo may wish to check alternative URLs for a page before bookmarking or annotating.
I don't have the big picture, but my gut feeling is that Diigo Meta may be useful in such situations. Users of installed versions for Firefox or Internet Explorer may find different workflows.
Tag: review
Diigo Meta does lead to the 'community' library for a site but at (for example) http://www.diigo.com/community/site/www.usatoday.com I see neither the URL that was bookmarked and annotated by me, nor the URL for the same page that was bookmarked and annotated by eight other people.
In other words, the community library views of things aren't helping me to avoid multiple bookmarks for essentially similar or identical content.