Subject: [Tools-discuss] Fwd: Re: Difficulty using DocumentInfo

From: Adam Roach <[email-masked]>
Date: Thu, 05 Apr 2012 12:51:04 -0500

Forwarding back to the tools mailing list, since we need to come to some 
kind of consensus on this.

/a

-------- Original Message --------
Subject: 	Re: [Tools-discuss] Difficulty using DocumentInfo
Date: 	Thu, 5 Apr 2012 10:48:04 -0700
From: 	Ryan Cross <[email-masked]>
To: 	Adam Roach <[email-masked]>

Yes, I agree the field name is inconsistent with how it's used and it should be fixed.  "filename" would be better.  I'll have to defer to Henrik to respond to model change requests (or he may have another solution).

On Apr 5, 2012, at 10:33 AM, Adam Roach wrote:

>  On 4/5/12 12:11 PM, Ryan Cross wrote:
>>  Hi Adam,
>>
>>  You are correct that meeting material documents (slides, agenda, and minutes) contain just a filename not a qualified URL in the external_url field.
>
>  Which is a fine bit of data to store, but -- um -- look at the field name and tell me how that makes any sense. This really makes what is otherwise a nice clean model difficult for beginners to get into.
>
>>  When converting the Meeting Material Manager tool I followed the precedent of the migration in the use of this field because we needed a place to store the disk filename 1) because it might differ from the Document.name and 2) to save the file extension.
>
>  Can we rename the field -- perhaps to something like "filename" -- before too much code gets written around it? This is the kind of crazy legacy hack we were trying to get away from with the migration.
>
>>    The method get_absolute_url() should return the information you are looking for.
>
>  Aha! Yes, that looks exactly like the option (c) I describe below. I'm a bit perplexed about why it is present on Document rather than DocumentInfo. It never even occurred to me to look there.
>
>  /a
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 05 Apr 2012 13:02:43 -0500

So, thinking about Ryan's involvement, I just realized something about 
this issue that makes it far more complicated than it has any right to be.

Ryan is working in the same database as we are, using the same models. 
But his stuff deploys on www.ietf.org

The code I work on deploys on datatracker.ietf.org.

Other stuff, using the same model, deploys on tools.ietf.org.

And then there's a pantheon of esoteric, one-off hosts like pub.ietf.org 
that presumably use the same data model.

None of these hosts have a harmonized URL scheme for accessing documents.

So there's no one method that can be added to the model that works for 
everyone.

We can address this partially by making sure that the main three 
authorities {www,tools,datatracker}.ietf.org use the same path scheme 
for accessing documents. I'm happy to make the changes to datatracker, 
but I *do* note that datatracker was recently changed *away* from using 
the same format at www -- so I want to get a "go ahead" from Henrik 
before I arguably undo someone else's work.

The alternative would be to add something ugly like get_www_url(), 
get_datatracker_url(), get_tools_url(), etc to the DocumentInfo class.

All of those feel like short-term hacks, through. I don't know what to 
do long-term, but the current situation is difficult and will be tricky 
to maintain.

/a

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 05 Apr 2012 23:22:36 +0200

Hi Adam, Ryan,

See the longer email I just sent in reply to Adam's first post -- the
use of the external_url field doesn't match the original intentions
for it, and sorting this out will need some cleanup.  We still will
need a way to get at both url and filename for a document, but the
external_url field was *only* intended to provide that for documents
which doesn't reside on the local file system.

Again, I consider the current mix-up a failure on my part to make clear
the intentions for that field.

Best regards,

	Henrik

On 2012-04-05 19:51 Adam Roach said the following:
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 05 Apr 2012 23:29:09 +0200

Hi Adam,

> None of these hosts have a harmonized URL scheme for accessing documents.

However, there presumably is a canonical location for all documents we
have.  (Which I see, as I read on, is something you propose further down)

But we maybe don't have to go there -- if we define get_path() and get_url()
methods for documents which use DOC_PATH and DOC_URL dictionaries in 
settings.py (which will be different for the different deployments) then
things should still work the same in all deployments.

> So there's no one method that can be added to the model that works for 

I think my proposal above would work, nevertheless...

> do long-term, but the current situation is difficult and will be tricky 

Let me know what you think of my proposal in my reply to your first note.

Best regards,

	Henrik

---

From: Adam Roach <[email-masked]>
Date: Thu, 05 Apr 2012 16:50:44 -0500

> have.  (Which I see, as I read on, is something you propose further down)

Pretty much, yes. But to be clear: I'd like to have the ability to get 
to documents via the same authority as my page (currently, 
datatracker.ietf.org for all the things I work on). For example, in 
order to resize iframes based on their contents, I need to be able to 
get to their DOM -- which I can do only if they are from the same 
origin. So the idea is that the same path gets you to the same document 
on multiple hosts.

/a

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 06 Apr 2012 12:56:20 +0200

Hi Adam,

> origin. So the idea is that the same path gets you to the same document 

Making this part of settings.py (through a per-document-prefix dictionary)
as I proposed in my first response to you should make the same code work
everywhere.

I do wonder, however, if maybe there are different use cases which need
to be accommodated (possibly with different get_*_url() methods) -- there's
your use case, which prefers same-host urls, and there's another where one
may explicitly prefer to point to the authoritative or canonical location
at which to retrieve a document.

Best regards,

	Henrik

---

From: Tony Hansen <[email-masked]>
Date: Fri, 06 Apr 2012 10:26:33 -0400

Are you suggesting that settings.py should have different 
per-document-prefix dictionaries for the different machines that you're 
running on?

If so, that's wrong: it needs to be per-document-prefix dictionaries for 
the different machines that you're publishing the path for.

Another strawman, instead of get_*_url(), perhaps we need something like:

get_url('datatracker', 'agendas', '99/whatever')

     Tony Hansen

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 08 Apr 2012 12:43:14 +0200

Hi Tony,

> per-document-prefix dictionaries for the different machines that you're 

Not necessarily, but it does cover the use-case Adam brought up, which
is that the secretariat are using the same models and code-base for the
tools on 'pub.ietf.org' as we are using on 'datatracker.ietf.org'.

Making the necessary differences in settings a part of settings.py seems
appropriate for this.

> get_url('datatracker', 'agendas', '99/whatever')

For the 'pub.ietf.org' vs. 'datatracker.ietf.org' case, Adam described,
that would make the code different, rather than just settings.py, no?

Best regards,

	Henrik