Context Refactoring

As is evident from previous messages, there is a big
question regarding
the whole "context" stuff.[1]

I believe that the general consensus is to clean up the
context stuff by
refactoring it.[2]

This post is to throw fuel on that fire, so that it doesn't
languish in
back alleys or get swept under the rug.

I am writing this as one that has a pressing need for the
new security
model, yet is unfamiliar with the context object as-is.  I'm
trying to
understand what it should be.  My goal is to:
  a) understand what the "context" object should
be
  b) bring the discussion out in the open

cmlenz created a google docs file where he started jotting
down his
thoughts, and invited any devs that wanted, to view it. 
osimons,
athomas, and cboos have all commented on it.  While I'm not
going to
reproduce it in its entirety, I am going to base my summary
on it.
Specifically, trying to incorporate the comments left by
osimons, aat,
and cboos.  I am really interested in feedback and help in
filling in my
lack of understanding.

<start really long post>

So the original goals of the context were:
  * fix for rendering relative links
  * enable fine-grained permissions
  * encapsulate "everything needed" (env, req, db)
in one object

This has lead to the cumbersome Context object that is
currently in trunk.

We're all for tossing out the last goal of encapsulating
everything in
the Context object

That leaves us with two semi-related purposes of the Context
object:
  1. permissions
  2. link rendering

The basis for these is the idea of a resource descriptor. 
Each resource
can be identified by a realm+identifier.

cmlenz's proposal is
{{{
  A resource descriptor is simply a list of tuples, for
example:

     [('wiki', ('WikiStart', 1))]
     [('wiki', ('WikiStart', 1)), ('attachment',
'README.txt')]
     [('ticket', 42), ('attachment', 'patch.diff')]

The list represents the containment hierarchy of a resource:
for
example, the attachment in the second list belongs to the
"WikiStart"
wiki page.

The individual tuples in a descriptor list are of the form
(realm,
identifier), where "realm" is a string, and
"identifier" is any
serializable and hashable object, such as a string or tuple.
For
example, wiki pages require both a page name and a version
number to be
uniquely identified, whereas attachments only require the
filename.
}}}

cmlenz thinks that simple data structures should be used due
to their
sufficiency and low overhead as descriptors will be
numerous.  As
descriptors will be used frequently, a convenience function
`.descriptor` could be added to the model objects so that it
would be
easy to get the descriptor of an object.

cboos tends to disagree with the use of simple data
structures due to
that being more of a resource identifier, rather than
resource
descriptor [more about this when talking about link
rendering] and the
cumbersomeness of manipulating lists of tuples.

cboos's alternative is to use a simple object that provides
properties
for `.realm`, `.id`, and `.version`.  He contends that this
will be
easier to extend to `.project` (multi-project support) or
something in
the future.

I tend to like the use of simple data structures though
admit that
`.realm`, etc. are easier to use.  However, I fail to see
how the object
will convey the hierarchy of a resource properly or easily.

osimons also suggested the possibility of using URI paths
for the
resource descriptors. For example:
'attachment/ticket/2048/2048.patch'

cboos raises concerns about this due to the need to parse
the path each
time the descriptor needed to be evaluated and the ambiguity
of the use
of '/'.

While I kind of agree with the parsing bit, I don't agree
with the
ambiguity.  The simple solution would be to URI encode the
string.  Then
'/'s are always separators, etc.  However, it could lead to
some really
ugly resource descriptors.

With the idea of a resource descriptor/identifier/???[3] in
hand, we can
tackle permissions and link rendering

= 1. Permissions =

Due to the presence of the resource descriptor, the
permission subsystem
can simply check whether or not the user has access to the
specified
resource.  It doesn't appear that there would need to be
many changes to
the permission system.  The biggest problem right now, is
that many
calls are made without specifying a realm.  I think that
while a full
resource descriptor may not be necessary, a realm should be
required.

cmlenz suggests:
{{{
  1. req.perm(realm, id=None)
  2. If realm is a list, treat it as a fully specified
resource descriptor.
  3. Otherwise treat (realm, id) as the descriptor.
}}}

osimons brings up the view that access to a resource
shouldn't be
allowed without the correct permissions.  This can be
accomplished by
using the "context" (resource descriptor?) as the
access method to
resources.  This would eliminate the need to plugin authors
to remember
to check security, or be able to horribly violate it
(unconsciously, at
least).

aat mentions his ideal fantasy land Trac would have three
layers internally:
{{{
  1.   The underlying data model (model.py) for raw data
access.
  2. An internal API for accessing the data while applying
permissions,
as well as other more complex manipulations of internal
resources. Kind
of like how WikiSystem and TicketSystem exist today, but
better defined
and more stable, and applied across all Trac modules.
  3. Then finally the API consumer, which would include the
Trac web
interface as well as third party plugins.
}}}

but notes that this is out of scope for the context
refactoring as the
context object hasn't really change how the permission
system is used.

cmlenz agrees with aat that that is out of scope.

One of the other benefits to a simple resource descriptor as
the basis
of the permission system is that it removes the dependence
on the
request object.  It is agreed that permission decisions
should be based
solely on the user accessing the resource and the resource
in question.

cboos raises the point that if the permission system isn't
going to be
tied to the request object, then there is no reason to use
req.perm as
the main entry point (other than backwards compatibility).
He proposes
the rendering context [see below about link rendering] as a
possibilty
for storing the permission info.  Or creating a `User`
object to wrap
the req.authname and permission cache.

I agree that if the permissions aren't tied to a request
(which I agree
they shouldn't) then using req.perm is kind of
counter-intuitive.
However, due to the need to release 0.11 sometime this
millennium, I
think that sticking with req.perm is the better choice.  I
think that a
separate class make sense, but should be slated for 0.12 or
0.13.

cboos also proposes a solution to providing access to
resources only if
the user has permissions.  More about this below under
"Appendix R -
Resource Class"

= 2. Link Rendering =

The `Context` stuff has done the following:
{{{
Thanks to Wiki rendering contexts, the following issues
could be solved:

  * relative attachments and comments TracLinks now always
refer to the
correct context resource, irrelevant from where they are
displayed
(ticket query with description #3711, headings #3842,
timeline, etc.)
  * relative links (i.e. [#anchor see this] kind of
TracLinks) are now
always referring to the correct resource (#4144)
}}}

cmlenz states:
{{{
Those two are of course related. I believe this can be
implemented by
simply passing a resource descriptor to the wiki_to_html()
function, and
storing it as a .resource  attribute on the Formatter 
object. The link
resolvers can then look at the resource descriptor and fixup
the
generating link accordingly.
...
The other thing that a context does is to determine whether
links should
be absolute (include the scheme and hostname) or relative to
the server
root. This had previously been an attribute on the wiki
formatter
object, and I think we should be able to simply move it back
there.
}}}

cboos rebuts:
{{{
We can't simply move all the responsibilities of the
rendering context
to the Formatter class, as Formatter objects are only
present when
explicitly rendering Wiki text, not generally available when
rendering
"content", in the mimeview module (the
"content" which is rendered is
coming from resources and that content may be wiki content).
So we need
something (a RenderingContext class?) that would be made
available to
the content renderers, and from there to the formatter, and
from the
formatter conveyed to the wiki processors.
}}}

This is where I get lost.  What cmlenz proposes seems to
make sense, and
  appears to the be simpler solution.  I'll admit that I
haven't really
delved into those parts of the code.  Why can't the
formatter be made
available to the mimeview stuff?  If it's so tied to the
wiki, why are
we even trying to use it with the mimeview stuff (via
Context, etc.)
Does this tie into the Context Factories and Subclasses [see
below]?  I
need some schooling here.

cmlenz mentions another feature of the Context class that is
similar to
the link rendering:
{{{
In the current code, the Context  class is also responsible
for
generating links to a resource. As far as I can tell, this
is a separate
enhancement that is only needed for the attachments module
and the newly
added "generic reports" feature.
}}}

== 2a. Context Factories and Subclasses ==
[note.  this is much of the stuff where I get kind of lost,
so I hope my
summary isn't too far off the mark]

Apparently, the these are used in the current Context stuff
to:
{{{
  * return the model object for a context
  * construct a URL to the resource identified by the
context
  * provide appropriate "name",
"shortname", and "summary" properties
}}}

Currently, the attachment module is the main user of this. 
It uses the
Context object to render the name and URL of the parent
resource.

cmlenz proposes an IResourceManager interface to handle such
things.[4]

On this topic, cboos opines:
{{{
We need some kind of dynamic description of resources, for
all the parts
that are generic about resources in Trac: the attachments,
the history
and diffs of resource content (#2945), the generic reports,
etc.
Those things have been built some time after the
WikiContext
integration, so it's true that they are separate
enhancements. But I
think that they are very worthwhile ones that have to be
kept and
probably expanded upon (generic comments, content change
annotation, etc.)
If there's really a need to decouple the way resources can
be identified
from the way resources can be described, then we could
eventually have
simple Resource objects and "rendering" methods
from a manager component
like the one suggested. That would actually make some parts
of the
implementation simpler, as we could create very simple
Resource objects
which could delegate their dynamic aspects to their managing
component.
}}}

I think this is agreeing with cmlenz (more or less).  Cboos
does propose
a modified interface for IResourceManager[5]

Now, I kind of like the idea of IResourceManager, but don't
fully grasp
the necessity.  Given that we decide a list of tuples is the
way to go
for the resource descriptor, doesn't the attachment module
already have
all that it needs to generate links to the parent object?

A resource for an attachment would be:
{{{
[('wiki', ('WikiStart', 1)), ('attachment', 'README.txt')]
}}}
so the attachment module knows what it's parent is.

Can someone clarify where we need the whole
IResourceManager/resource
description stuff?

= Appendix R - Resource Class =

cboos's solution to osimons's security suggestion is to run
all access
to resources through req.perm.  Basically add
req.perm.resource() that
would return the resource if permissions allowed, or raise
an error (or
return none in the case of req.perm.get_resource())

Example usage:
{{{
page = req.perm.resource('wiki', 'WikiStart')
wiki = req.perm.resource('wiki')
wiki = req.perm.get_resource('wiki') # return None if not
authorized
}}}

The proposal is a bit more extensive, but this has already
been an epic.

= Conclusion =

Due to the nature of this beast, I'm inclined to say that
less is more.
  I do like osimons's security idea, but I agree with cmlenz
and aat
that it's out of scope for 0.11.  Cboos's compromise doesn't
look bad,
but I think think it's something that would be too rushed
for 0.11.
Better leave it out and do it properly for 0.12 or 0.13

I don't fully understand the issues surrounding the whole
"resource
description" vs "resource identification"
stuff.  I don't quite see the
benefit to the IResourceManager interface.   Why is it that
we really
need it in the first place?

I'm definitely for a very simple descriptor/identifier for
resources.
It makes security easy and flexible.  Rendering stuff isn't
needed there.

So I'd love to be schooled as to all the things that I'm not
taking into
consideration, or to where I've completely missed the mark
in this
discussion.  I'd also love to see some kind of consensus
sooner rather
than later (as I'm sure most people would).  But I don't
think that's
going to happen until we really talk about it.

Sorry for the epic novel.

-John

[1] http://groups.google.com/group/trac-dev/msg/e3543733
f1c25eec
[2] http://groups.google.com/group/trac-dev/msg/e5a85040
770b130e
[3] henceforth referred to as "resource
descriptor" regardless of
whether it is more of a simple identifier or not.
[4]
{{{
class IResourceManager(Interface):

     def get_resource_realm():
         """Return the string identifying the
realm of resources
         handled by this component."""

     def get_resource_url(descriptor, href, **kwargs):
         """Return the URL for the requested
resource."""

     def resolve_resource(descriptor):
         """Return an object representing the
content of the
         requested resource.

         The returned object needs to have at least the
following
         properties and functions:
         * `__unicode()__`: should return a compact
representation
           of the object, such as "#123" for the
ticket with the ID
           123
         * `display_name`: a more verbose string
representation of
           the object, for example "Ticket #123"
for the ticket with
           the ID 123
         """
}}}
[5]
{{{
class IResourceManager(Interface):

     def get_resource_realms():
         """Generate realm strings
identifying the realm
         of resources handled by this
component."""

     def get_model(resource):
         """Return an object representing the
content of
         the requested resource.
         """

     def get_resource_url(resource, href, **kwargs):
         """Return the URL for the requested
resource."""

     def get_resource_description(resource, format=None):
         """Return a representation of the
resource,
         according to the `format`.

         For example, the ticket with the ID 123 is
         represented like `'#123'` for the `'compact'`
format,
         `'Ticket #123'` for the default `None` format.
         With the `'summary'` format, more details about
the
         resource will be given, at the expense of a lookup
to
         the resource's model.
         """
}}}



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

After having sent the epic, I forgot to mention that the
google doc 
discussion has been moved to the t.e.o wiki

http://trac.edgewall.org/wiki/TracDev/ContextRefactoring


-John

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Hello paco,

First, sorry if this post appears twice - this one is resent
from
groupsgoogle (with minor edits), as my original mail didn't
get
through after an hour...


John Hampton wrote:
> As is evident from previous messages, there is a big
question regarding
> the whole "context" stuff.[1]
>
> I believe that the general consensus is to clean up the
context stuff by
> refactoring it.[2]
>
> This post is to throw fuel on that fire, so that it
doesn't languish in
> back alleys or get swept under the rug.
>

Thanks for providing this summary. As you probably figured
out, that
document and more specifically my parts are quite in a
"work-in-progress" state, so there were probably
contradictions, the
most notable one being about the use of req.perm.
I'll try to address some of your questions below, where you
requested
some clarifications.

> ...
> That leaves us with two semi-related purposes of the
Context object:
>   1. permissions
>   2. link rendering
>
> The basis for these is the idea of a resource
descriptor.  Each resource
> can be identified by a realm+identifier.
>
> ...
> cboos tends to disagree with the use of simple data
structures due to
> that being more of a resource identifier, rather than
resource
> descriptor [more about this when talking about link
rendering] and the
> cumbersomeness of manipulating lists of tuples.
> ... However, I fail to see how the object
> will convey the hierarchy of a resource properly or
easily.
>

resource.parent?

> = 1. Permissions =
>
> ...
> cboos raises the point that if the permission system
isn't going to be
> tied to the request object, then there is no reason to
use req.perm as
> the main entry point (other than backwards
compatibility). He proposes
> the rendering context [see below about link rendering]
as a possibilty
> for storing the permission info.  Or creating a `User`
object to wrap
> the req.authname and permission cache.
>

Well, actually the PermissionCache is all we need. The fact
that it
is
originally attached to 'req' can be safely ignored 

> = 2. Link Rendering =
>
> ...
>
> cboos rebuts:
> {{{
> We can't simply move all the responsibilities of the
rendering context
> to the Formatter class, as Formatter objects are only
present when
> explicitly rendering Wiki text, not generally available
when rendering
> "content", in the mimeview module (the
"content" which is rendered is
> coming from resources and that content may be wiki
content). So we need
> something (a RenderingContext class?) that would be
made available to
> the content renderers, and from there to the formatter,
and from the
> formatter conveyed to the wiki processors.
> }}}
>
> This is where I get lost.  What cmlenz proposes seems
to make sense, and
>   appears to the be simpler solution.  I'll admit that
I haven't really
> delved into those parts of the code.  Why can't the
formatter be made
> available to the mimeview stuff?  If it's so tied to
the wiki, why are
> we even trying to use it with the mimeview stuff (via
Context, etc.)
> Does this tie into the Context Factories and Subclasses
[see below]?  I
> need some schooling here.
>

Quite simply, the wiki engine is layered on top of the
mimeview
layer,
so the formatter can't be made available to the mimeview
layer. OTOH,
there are various parts of the rendering engine that need to
be able
to
know about the "resource" being manipulated (e.g.
the blame stuff).
But I agree that at the time you were reading the proposal,
the part
of
the RenderingContext was rather vague, and that's normal
because I'm
working on that  right now 

> == 2a. Context Factories and Subclasses ==
> [note.  this is much of the stuff where I get kind of
lost, so I hope my
> summary isn't too far off the mark]
>
> Apparently, the these are used in the current Context
stuff to:
> {{{
>   * return the model object for a context
>   * construct a URL to the resource identified by the
context
>   * provide appropriate "name",
"shortname", and "summary" properties
> }}}
>
> Currently, the attachment module is the main user of
this.  It uses the
> Context object to render the name and URL of the parent
resource.
>
> cmlenz proposes an IResourceManager interface to handle
such things.[4]
>
> On this topic, cboos opines:
> {{{
> We need some kind of dynamic description of resources,
for all the parts
> that are generic about resources in Trac: the
attachments, the history
> and diffs of resource content (#2945), the generic
reports, etc.
> Those things have been built some time after the
WikiContext
> integration, so it's true that they are separate
enhancements. But I
> think that they are very worthwhile ones that have to
be kept and
> probably expanded upon (generic comments, content
change annotation, etc.)
> If there's really a need to decouple the way resources
can be identified
> from the way resources can be described, then we could
eventually have
> simple Resource objects and "rendering"
methods from a manager component
> like the one suggested. That would actually make some
parts of the
> implementation simpler, as we could create very simple
Resource objects
> which could delegate their dynamic aspects to their
managing component.
> }}}
>
> I think this is agreeing with cmlenz (more or less). 
Cboos does propose
> a modified interface for IResourceManager[5]
>
> Now, I kind of like the idea of IResourceManager, but
don't fully grasp
> the necessity.  Given that we decide a list of tuples
is the way to go
> for the resource descriptor, doesn't the attachment
module already have
> all that it needs to generate links to the parent
object?
>
> A resource for an attachment would be:
> {{{
> [('wiki', ('WikiStart', 1)), ('attachment',
'README.txt')]
> }}}
> so the attachment module knows what it's parent is.
>
> Can someone clarify where we need the whole
IResourceManager/resource
> description stuff?
>

The attachment module has no idea about the conventions for
rendering
a
page name or a ticket number.
For sure, the attachment page could display something like:
"Attachment
proposal.txt for wiki:WikiStart" or "Attachment
sreenshot.jpg for
ticket:123", but it's nicer to display stuff like:
"Attachment
proposal.txt for WikiStart" or "Attachment
sreenshot.jpg for Ticket
#123", and for that we're simply using
"parent.name" in the template.
Same thing for a summary, which for a ticket shows
information about
title, state and resolution.

> = Appendix R - Resource Class =
>
> cboos's solution to osimons's security suggestion is to
run all access
> to resources through req.perm.  Basically add
req.perm.resource() that
> would return the resource if permissions allowed, or
raise an error (or
> return none in the case of req.perm.get_resource())
>
> Example usage:
> {{{
> page = req.perm.resource('wiki', 'WikiStart')
> wiki = req.perm.resource('wiki')
> wiki = req.perm.get_resource('wiki') # return None if
not authorized
> }}}
>
> The proposal is a bit more extensive, but this has
already been an epic.
>

"run all access to resources through req.perm" ...
or already
available
resources.

> = Conclusion =
>
> Due to the nature of this beast, I'm inclined to say
that less is more.
>   I do like osimons's security idea, but I agree with
cmlenz and aat
> that it's out of scope for 0.11.

I think what they stated to be out of the scope for 0.11 is
a layer
of
the application logic which would take the permissions into
account
(as
opposed to the all the permission checks at the web_ui
level).

>  Cboos's compromise doesn't look bad,
> but I think think it's something that would be too
rushed for 0.11.
> Better leave it out and do it properly for 0.12 or
0.13
>

Well, the point is to discuss a way to do fine grained
permission in
0.11 until we get it "right", so I don't see how
this is rushed...

> I don't fully understand the issues surrounding the
whole "resource
> description" vs "resource
identification" stuff.  I don't quite see the
> benefit to the IResourceManager interface.   Why is it
that we really
> need it in the first place?
>

I hope I clarified that in the attachment example above, but
there
are
many other places where we manipulate Trac resources in a
more or
less
generic way.

> I'm definitely for a very simple descriptor/identifier
for resources.
> It makes security easy and flexible.  Rendering stuff
isn't needed there.
>

No, of course it isn't needed for security checks, but it's
simply
convenient to be able to use an already available resource
identifier
in
order to get a few simple informations out of it and even
more
informations by retrieving its associated model. The
name/shortname
etc.
properties are already delegating the rendering to the
IResourceManager
component (the resource.manager). An alternative approach
would be to
have the resource identifier provide a resource descriptor
(an object
more lightweight than the model), which could then be used
to have
the
desired rendering (i.e. something like page.descriptor.name
instead
of
just page.name), but I'm not sure this additional complexity
is worth
it

I hope I answered your questions.

PS: I've just noticed
http://trac.edgewall.org/wiki/TracDev/ContextRefactoring
 - thanks for
doing the conversion! If there's a need to update the
proposal, I
think this should be the authoritative place, now.

-- Christian


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

On 9/25/07, Christian Boos <cboosneuf.fr> wrote:
> Well, the point is to discuss a way to do fine grained
permission in
> 0.11 until we get it "right", so I don't see
how this is rushed...

Leaving what the point is for now, it seems to me that the
point
*should* be how to get 0.11 out the door, while only fixing
what's
really "broken" at this point (i.e. bad API's).
This release cycle has
taken way too long already...

Cheers,

Manuzhai

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

On 9/25/07, John Hampton <pacopablopacopablo.com> wrote:
> osimons also suggested the possibility of using URI
paths for the
> resource descriptors. For example:
'attachment/ticket/2048/2048.patch'
>
> cboos raises concerns about this due to the need to
parse the path each
> time the descriptor needed to be evaluated and the
ambiguity of the use
> of '/'.
>
> While I kind of agree with the parsing bit, I don't
agree with the
> ambiguity.  The simple solution would be to URI encode
the string.  Then
> '/'s are always separators, etc.  However, it could
lead to some really
> ugly resource descriptors.

Hi, thanks for your summary of the issue.  I was starting to
get a
little lost too.

Yes, in an earlier implementation I had of fine-grained
permissions,
URI paths like that were used as resource identifiers, and
it quickly
became cumbersome.  This is in fact still in use in the
database, but
they are quickly parsed into something more useful.  So if
one were to
store resource identifiers in a database it's not terrible,
but some
more useful data structure is needed for use by the API.  I
haven't
decided which I like better of the solutions that have been
suggested
at this point.  Of course, you still want a normal method
of
converting a resource identifier to a URI.

> The biggest problem right now, is that many
> calls are made without specifying a realm.  I think
that while a full
> resource descriptor may not be necessary, a realm
should be required.
>
> cmlenz suggests:
> {{{
>   1. req.perm(realm, id=None)
>   2. If realm is a list, treat it as a fully specified
resource descriptor.
>   3. Otherwise treat (realm, id) as the descriptor.
> }}}

I really like this idea.  A little while ago I was tasked
with
enhancing the permission system to allow ticket permissions
to be set
based on a ticket's type (defect, enhancement, etc). 
Usually, when
checking such permissions, a specific ticket resource is
dealt with.
But sometimes it isn't.  For example, when checking the
TICKET_CREATE
permission for whether or not the 'New Ticket' menu item
should be
shown, as long as they can create tickets of one type, the
check_permission function should return true.  In other
words, it's
useful to check permissions by realm as well as by
resource.

> the main entry point (other than backwards
compatibility). He proposes
> the rendering context [see below about link rendering]
as a possibilty
> for storing the permission info.  Or creating a `User`
object to wrap
> the req.authname and permission cache.

I have also implemented something like this with success on
a
different project.  It used an LRU cache of User objects
that stored
each user's permissions.  Unfortunately, it was still
necessary to
keep a timestamp in the database each time a user's
permissions were
updated, and to check that timestamp every time the user's
permissions
were looked up.  But it was still fairly efficient--it
reduced several
more time-consuming operations per request to one small DB
query and
hash table lookup.  Trac's permission system is much more
lightweight
to begin with though, so I doubt anyone would want that
added
complexity.

> I agree that if the permissions aren't tied to a
request (which I agree
> they shouldn't) then using req.perm is kind of
counter-intuitive.
> However, due to the need to release 0.11 sometime this
millennium, I
> think that sticking with req.perm is the better choice.
 I think that a
> separate class make sense, but should be slated for
0.12 or 0.13.

Yeah, it's useful sometimes to check a user's permissions
outside the
context of a specific request.  But it will have to stay for
now, and
req.perm could still easily be kept in the future for
backwards
compatability.

Erik

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Am 25.09.2007 um 12:02 schrieb Christian Boos:
> John Hampton wrote:
>> ...
>> That leaves us with two semi-related purposes of
the Context object:
>>   1. permissions
>>   2. link rendering
>>
>> The basis for these is the idea of a resource
descriptor.  Each  
>> resource
>> can be identified by a realm+identifier.
>>
>> ...
>> cboos tends to disagree with the use of simple data
structures due to
>> that being more of a resource identifier, rather
than resource
>> descriptor [more about this when talking about link
rendering] and  
>> the
>> cumbersomeness of manipulating lists of tuples.
>> ... However, I fail to see how the object
>> will convey the hierarchy of a resource properly or
easily.
> resource.parent?

I stick to my proposal of using a simple list of tuples.
Yeah,  
"resource descriptors" is a misnomer, let's just
call them "resource  
identifiers" (as you have done).

*If* we at some point want to add a project component to the
 
containment heirarchy, it'd probably just look like this:

  [('project', 'Foo'), ('wiki', ('WikiStart', 1))]

But to be honest, I'm not sure whether much of our stuff
will survive  
a move to true multi-project support.

Furthermore, I think some of the examples for resource
identifiers  
are bogus. For example, you'll *never* have something like:

  [('wiki', ('WikiStart', 1)), ('query', None), ('ticket',
1))]

Ticket #1, even if embedded into a wiki page through a query
macro or  
something, is still an independent resource that is
completely  
identified by ('ticket', 1). If you think the above example
is valid,  
you're confusing resource identifiers with the context in
which  
resources are embedded, which are two separate things that
we really  
ought not confuse.

Furthermore, I think the argument that we'd need to be
creating and  
manipulating these things in a generic way very often, which
would  
demand a more convenient construction/manipulation API, is
also  
incorrect AFAICT. In many cases, we already have a model
object at  
hand, and doing something like ticket.identifier to get the
resource  
identifer is as convenient as it gets. In most other cases,
we deal  
with just a single-item list, and constructing it via
[(realm, id)]  
is as simple as it gets. Any other cases (e.g. in the
attachment  
module) require just a simple list concatenation.

I would really prefer attempting this
"as-lightweight-as-possible"  
approach first before trying to come up with some
higher-level class- 
based design.

>> = 1. Permissions =
>>
>> ...
>> cboos raises the point that if the permission
system isn't going  
>> to be
>> tied to the request object, then there is no reason
to use  
>> req.perm as
>> the main entry point (other than backwards
compatibility). He  
>> proposes
>> the rendering context [see below about link
rendering] as a  
>> possibilty
>> for storing the permission info.  Or creating a
`User` object to wrap
>> the req.authname and permission cache.
>>
>
> Well, actually the PermissionCache is all we need. The
fact that it
> is originally attached to 'req' can be safely ignored


Right, the cited code was an example, and does not mean you
*have* to  
access the PermissionCache object through the req. It could
have been  
passed to you directly, for example.

>> = 2. Link Rendering =
>>
>> ...
>>
>> cboos rebuts:
>> {{{
>> We can't simply move all the responsibilities of
the rendering  
>> context
>> to the Formatter class, as Formatter objects are
only present when
>> explicitly rendering Wiki text, not generally
available when  
>> rendering
>> "content", in the mimeview module (the
"content" which is rendered is
>> coming from resources and that content may be wiki
content). So we  
>> need
>> something (a RenderingContext class?) that would be
made available to
>> the content renderers, and from there to the
formatter, and from the
>> formatter conveyed to the wiki processors.
>> }}}
>>
>> This is where I get lost.  What cmlenz proposes
seems to make  
>> sense, and
>>   appears to the be simpler solution.  I'll admit
that I haven't  
>> really
>> delved into those parts of the code.  Why can't the
formatter be made
>> available to the mimeview stuff?  If it's so tied
to the wiki, why  
>> are
>> we even trying to use it with the mimeview stuff
(via Context, etc.)
>> Does this tie into the Context Factories and
Subclasses [see  
>> below]?  I
>> need some schooling here.
> Quite simply, the wiki engine is layered on top of the
mimeview
> layer, so the formatter can't be made available to the
mimeview  
> layer. OTOH,
> there are various parts of the rendering engine that
need to be able
> to know about the "resource" being
manipulated (e.g. the blame stuff).
> But I agree that at the time you were reading the
proposal, the part
> of the RenderingContext was rather vague, and that's
normal because  
> I'm
> working on that  right now 

Okay, this area needs more consideration.

>> == 2a. Context Factories and Subclasses ==
>> [note.  this is much of the stuff where I get kind
of lost, so I  
>> hope my
>> summary isn't too far off the mark]
>>
>> Apparently, the these are used in the current
Context stuff to:
>> {{{
>>   * return the model object for a context
>>   * construct a URL to the resource identified by
the context
>>   * provide appropriate "name",
"shortname", and "summary" properties
>> }}}
>>
>> Currently, the attachment module is the main user
of this.  It  
>> uses the
>> Context object to render the name and URL of the
parent resource.
>>
>> cmlenz proposes an IResourceManager interface to
handle such  
>> things.[4]
>>
>> On this topic, cboos opines:
>> {{{
>> We need some kind of dynamic description of
resources, for all the  
>> parts
>> that are generic about resources in Trac: the
attachments, the  
>> history
>> and diffs of resource content (#2945), the generic
reports, etc.
>> Those things have been built some time after the
WikiContext
>> integration, so it's true that they are separate
enhancements. But I
>> think that they are very worthwhile ones that have
to be kept and
>> probably expanded upon (generic comments, content
change  
>> annotation, etc.)
>> If there's really a need to decouple the way
resources can be  
>> identified
>> from the way resources can be described, then we
could eventually  
>> have
>> simple Resource objects and "rendering"
methods from a manager  
>> component
>> like the one suggested. That would actually make
some parts of the
>> implementation simpler, as we could create very
simple Resource  
>> objects
>> which could delegate their dynamic aspects to their
managing  
>> component.
>> }}}
>>
>> I think this is agreeing with cmlenz (more or
less).  Cboos does  
>> propose
>> a modified interface for IResourceManager[5]
>>
>> Now, I kind of like the idea of IResourceManager,
but don't fully  
>> grasp
>> the necessity.  Given that we decide a list of
tuples is the way  
>> to go
>> for the resource descriptor, doesn't the attachment
module already  
>> have
>> all that it needs to generate links to the parent
object?
>>
>> A resource for an attachment would be:
>> {{{
>> [('wiki', ('WikiStart', 1)), ('attachment',
'README.txt')]
>> }}}
>> so the attachment module knows what it's parent
is.
>>
>> Can someone clarify where we need the whole
IResourceManager/resource
>> description stuff?
>>
>
> The attachment module has no idea about the conventions
for rendering
> a page name or a ticket number.
> For sure, the attachment page could display something
like:
> "Attachment proposal.txt for wiki:WikiStart"
or "Attachment  
> sreenshot.jpg for
> ticket:123", but it's nicer to display stuff like:
"Attachment
> proposal.txt for WikiStart" or "Attachment
sreenshot.jpg for Ticket
> #123", and for that we're simply using
"parent.name" in the template.
> Same thing for a summary, which for a ticket shows
information about
> title, state and resolution.

Can you enlighten me about where this "summary" is
actually needed?

>> = Appendix R - Resource Class =
>>
>> cboos's solution to osimons's security suggestion
is to run all  
>> access
>> to resources through req.perm.  Basically add
req.perm.resource()  
>> that
>> would return the resource if permissions allowed,
or raise an  
>> error (or
>> return none in the case of
req.perm.get_resource())
>>
>> Example usage:
>> {{{
>> page = req.perm.resource('wiki', 'WikiStart')
>> wiki = req.perm.resource('wiki')
>> wiki = req.perm.get_resource('wiki') # return None
if not authorized
>> }}}
>>
>> The proposal is a bit more extensive, but this has
already been an  
>> epic.
>
> "run all access to resources through
req.perm" ... or already
> available
> resources.
>
>> = Conclusion =
>>
>> Due to the nature of this beast, I'm inclined to
say that less is  
>> more.
>>   I do like osimons's security idea, but I agree
with cmlenz and aat
>> that it's out of scope for 0.11.
>
> I think what they stated to be out of the scope for
0.11 is a layer
> of the application logic which would take the
permissions into account
> (as opposed to the all the permission checks at the
web_ui level).

I can't speak for Alec, but I really meant that this whole
problem  
space is out of scope for 0.11. Permission checks should
remain  
something that's done in the web interface for the time
being.

>>  Cboos's compromise doesn't look bad,
>> but I think think it's something that would be too
rushed for 0.11.
>> Better leave it out and do it properly for 0.12 or
0.13
>>
> Well, the point is to discuss a way to do fine grained
permission in
> 0.11 until we get it "right", so I don't see
how this is rushed...

Allowing fine grained (i.e. object level) authorization is
very  
different from adding an API that enforces code to consider 

permissions, or even from adding an API that makes it more 

convenient. Again, I'm strongly against this kind of thing
going into  
0.11, although I do think it'd be important in the long
term.

>> I'm definitely for a very simple
descriptor/identifier for resources.
>> It makes security easy and flexible.  Rendering
stuff isn't needed  
>> there.
> No, of course it isn't needed for security checks, but
it's simply
> convenient to be able to use an already available
resource identifier
> in order to get a few simple informations out of it and
even more
> informations by retrieving its associated model. The
name/shortname
> etc. properties are already delegating the rendering to
the
> IResourceManager component (the resource.manager). An
alternative  
> approach would be to
> have the resource identifier provide a resource
descriptor (an object
> more lightweight than the model), which could then be
used to have
> the desired rendering (i.e. something like
page.descriptor.name  
> instead
> of just page.name), but I'm not sure this additional
complexity is  
> worth
> it
>
> I hope I answered your questions.

Again, I'd really prefer us at least *trying* to go without
an actual  
"Resource(Descriptor)" class first. The resource
identifier (as list  
of tuples) and an IResourceManager interface (modified so
that you  
don't need to fetch a model instance to get display names)
should be  
enough for enabling fine-grained permissions, the generic
TracObject- 
ish stuff in the attachments module etc, and relative links
in Wiki  
text.

Adding a rendering context needs more discussion. Do you
have a  
direct link to a proposal of yours handy?

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Hello,

Hm, it looks like your answer didn't cover the updated
proposal of
this morning:

http://trac.ed
gewall.org/wiki/TracDev/ContextRefactoring#TheResourceclassf
orresourceidentification

(I've sent a mail about it on Trac-dev, but apparently I'm
having
trouble with my e-mail provider - this one is posted from
google
groups).

There are also a few code samples from the prototype.

Now to answer the points:

On Sep 27, 7:15 pm, Christopher Lenz <cml...gmx.de> wrote:
> I stick to my proposal of using a simple list of
tuples. Yeah,
> "resource descriptors" is a misnomer, let's
just call them "resource
> identifiers" (as you have done).
>
> *If* we at some point want to add a project component
to the
> containment heirarchy, it'd probably just look like
this:
>
>   [('project', 'Foo'), ('wiki', ('WikiStart', 1))]
>
> But to be honest, I'm not sure whether much of our
stuff will survive
> a move to true multi-project support.

Well, another point where we differ. I see a quite clear
path from now
to multiple project support:

http://trac.edgewall.
org/wiki/TracMultipleProjects/SingleEnvironment#ProposedImpl
ementation



> Furthermore, I think some of the examples for resource
identifiers
> are bogus. For example, you'll *never* have something
like:
>
>   [('wiki', ('WikiStart', 1)), ('query', None),
('ticket', 1))]
>
> Ticket #1, even if embedded into a wiki page through a
query macro or
> something, is still an independent resource that is
completely
> identified by ('ticket', 1). If you think the above
example is valid,
> you're confusing resource identifiers with the context
in which
> resources are embedded, which are two separate things
that we really
> ought not confuse.

You're talking about the old Context here, no?
Remember that it's mainly because I acknowledged the need
for a
distinction here that I was willing to make the split
between resource
identifiers and rendering context.

What you describe above is a RenderingContext, which is
basically a
stack of Resource identifiers. The Resource identifiers
themselves
have a  different notion of parenting (mainly for now: an
attachment
Resource is a child of e.g. a Wiki Resource).


>
> Furthermore, I think the argument that we'd need to be
creating and
> manipulating these things in a generic way very often,
which would
> demand a more convenient construction/manipulation API,
is also
> incorrect AFAICT. In many cases, we already have a
model object at
> hand, and doing something like ticket.identifier to get
the resource
> identifer is as convenient as it gets.

Well, data model instance creation is costly especially in
the
timeline event providers and search providers, but also in
report and
query results.

> In most other cases, we deal
> with just a single-item list, and constructing it via
[(realm, id)]
> is as simple as it gets. Any other cases (e.g. in the
attachment
> module) require just a simple list concatenation.

... as long as it stays like that. I find that using simple
list
manipulation like [-1][0], and this sort of things is error
prone and
not very future proof (vs. resource.realm, resource.id,
resource.version and later maybe resource.project and
resource.field
if we want that level of detail...)


> I would really prefer attempting this
"as-lightweight-as-possible"
> approach first before trying to come up with some
higher-level class-
> based design.
>

Well, it's stays quite light-weight - only a Resource class,
no object
hierarchy. It's pretty simple.

>
>
> >> = 1. Permissions =
>
> >> ...
> >> cboos raises the point that if the permission
system isn't going
> >> to be
> >> tied to the request object, then there is no
reason to use
> >> req.perm as
> >> the main entry point (other than backwards
compatibility). He
> >> proposes
> >> the rendering context [see below about link
rendering] as a
> >> possibilty
> >> for storing the permission info.  Or creating
a `User` object to wrap
> >> the req.authname and permission cache.
>
> > Well, actually the PermissionCache is all we need.
The fact that it
> > is originally attached to 'req' can be safely
ignored 
>
> Right, the cited code was an example, and does not mean
you *have* to
> access the PermissionCache object through the req. It
could have been
> passed to you directly, for example.

Here we agree.


>
>
> >> = 2. Link Rendering =
>
> >> ...
>
> Okay, this area needs more consideration.

See the updated proposal and the code samples.
But I agree that there's more to it than that, like better
mime-type
support in the future (re #3332).


> >> == 2a. Context Factories and Subclasses ==
>
> Can you enlighten me about where this
"summary" is actually needed?
>

Well, it's perhaps not used right now, I have to check
(sorry, I'm a
bit short on time).



> >> = Appendix R - Resource Class =
>
> >> cboos's solution to osimons's security
suggestion is to run all
> >> access
> >> to resources through req.perm.  Basically add
req.perm.resource()
> >> that
> >> would return the resource if permissions
allowed, or raise an
> >> error (or
> >> return none in the case of
req.perm.get_resource())
>

> I can't speak for Alec, but I really meant that this
whole problem
> space is out of scope for 0.11. Permission checks
should remain
> something that's done in the web interface for the time
being.
>


Well, that's still the case. The permission checks are done
nearly the
same way as before.


> >>  Cboos's compromise doesn't look bad,
> >> but I think think it's something that would be
too rushed for 0.11.
> >> Better leave it out and do it properly for
0.12 or 0.13
>
> > Well, the point is to discuss a way to do fine
grained permission in
> > 0.11 until we get it "right", so I don't
see how this is rushed...
>
> Allowing fine grained (i.e. object level) authorization
is very
> different from adding an API that enforces code to
consider
> permissions, or even from adding an API that makes it
more
> convenient. Again, I'm strongly against this kind of
thing going into
> 0.11, although I do think it'd be important in the long
term.


Well, I don't really understand your objections here.
Can you be more precise, in particular how this would apply
to the
code samples I supplied?


> >> I'm definitely for a very simple
>
> ...
>
> read more >>
Woops, is that google cutting the quoted text?
Anyway, I've run out of time 

(discussion to be continued)

-- Christian


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Am 27.09.2007 um 19:43 schrieb Christian Boos:
> Hm, it looks like your answer didn't cover the updated
proposal of
> this morning:
>
> http://trac.ed
gewall.org/wiki/TracDev/ 
>
ContextRefactoring#TheResourceclassforresourceidentification


To quote:

   "As fine-grained security and permission checks are
becoming the  
rule in Trac, one shouldn't be able to access a resource
without the  
appropriate credentials."

I *strongly* disagree with this. That *may* be something to
think  
about for a future release, but most definitely not for
0.11.

And the whole concept of "resources have to be created
through the  
permission system" is wrong IMO. But that's not the
point. The point  
is that we should not be thinking about doing anything like
that for  
0.11. Both Alec and myself have stated early on that we
think this  
was out of scope for the release.

My idea (and I think I'm not alone here) was that we should
go back  
and fix Context by removing/simplifying. What you're
proposing here  
seems to go in a totally different direction.

> On Sep 27, 7:15 pm, Christopher Lenz <cml...gmx.de> wrote:
>> Furthermore, I think some of the examples for
resource identifiers
>> are bogus. For example, you'll *never* have
something like:
>>
>>   [('wiki', ('WikiStart', 1)), ('query', None),
('ticket', 1))]
>>
>> Ticket #1, even if embedded into a wiki page
through a query macro or
>> something, is still an independent resource that is
completely
>> identified by ('ticket', 1). If you think the above
example is valid,
>> you're confusing resource identifiers with the
context in which
>> resources are embedded, which are two separate
things that we really
>> ought not confuse.
>
> You're talking about the old Context here, no?
> Remember that it's mainly because I acknowledged the
need for a
> distinction here that I was willing to make the split
between resource
> identifiers and rendering context.
>
> What you describe above is a RenderingContext, which is
basically a
> stack of Resource identifiers. The Resource identifiers
themselves
> have a  different notion of parenting (mainly for now:
an attachment
> Resource is a child of e.g. a Wiki Resource).

What I meant was that I've seen examples of stuff that
wouldn't ever  
be an actual resource identifier. I may have gotten the
wrong  
impression here, or may be misremembering the examples

Anyway, I strongly doubt we'll need to identify the
"resource/ 
context" in which some other resource is being
rendered. The only use  
case I can think of are relative links (as in ../foo instead
of /bar/ 
foo), and those are more trouble than they're worth. That's
not to  
say that the idea of a "rendering context" isn't
needed, just that  
that context doesn't need to know about the
(pseudo-)resource in  
which it's being used.

>> Furthermore, I think the argument that we'd need to
be creating and
>> manipulating these things in a generic way very
often, which would
>> demand a more convenient construction/manipulation
API, is also
>> incorrect AFAICT. In many cases, we already have a
model object at
>> hand, and doing something like ticket.identifier to
get the resource
>> identifer is as convenient as it gets.
>
> Well, data model instance creation is costly especially
in the
> timeline event providers and search providers, but also
in report and
> query results.

Well, elsewhere in my mail I said that there should be ways
to get  
display_name etc without going through a DB lookup. Just
adding a  
get_resource_info() method (or similar) to the
IResourceManager  
interface I proposed would do the trick, while still not
requiring  
the use of resource "descriptors" as opposed to
simple identifiers.

[snipped lots]

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Christopher" == Christopher
Lenz <cmlenzgmx.de> writes:
   Christopher>    "As fine-grained security and
permission checks are
    Christopher> becoming the rule in Trac, one shouldn't
be able to
    Christopher> access a resource without the
appropriate credentials."

    Christopher> I *strongly* disagree with this. That
*may* be
    Christopher> something to think about for a future
release, but most
    Christopher> definitely not for 0.11.

  I concur. Baby steps.
  Please release more often.

- -- 
Michael Richardson <mcrxdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/
mcr/ 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQDVAwUBRwaIFe0sRu40D6vCAQLs7gX7BXX6LKRtOBWsbDnZU+9kcQIHdNBD
YXZ5
rvx2HQDLWJjXc3bYS3LIHGVbiX3LilNCsd9FLU+J1taYpl8AtNABd3rLyjv6
UILH
9dF0fZuPf81KVSu5xBD5Rt7RVDAI3lEv8oRwU8d5hZWTVUT4lxrtJhxZxgUo
Qs8b
qqXGul+UPon9hqgYX9EcBASMnBoWINOlkKuB708QqvxwmovTth/0FYL79ZGD
HPWF
YoeJi7Iz4zIoy1Scf9dhu1FrgO+HgBFN
=cGin
-----END PGP SIGNATURE-----

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Christopher Lenz wrote:
>    "As fine-grained security and permission checks
are becoming the  
> rule in Trac, one shouldn't be able to access a
resource without the  
> appropriate credentials."
> 
> I *strongly* disagree with this. That *may* be
something to think  
> about for a future release, but most definitely not for
0.11.

I agree that it should not be targeted for 0.11

> My idea (and I think I'm not alone here) was that we
should go back  
> and fix Context by removing/simplifying. What you're
proposing here  
> seems to go in a totally different direction.

That's how I feel too.

<snip mucho re: rendering contexts>

> What I meant was that I've seen examples of stuff that
wouldn't ever  
> be an actual resource identifier. I may have gotten the
wrong  
> impression here, or may be misremembering the examples

It would be interesting to know what examples these might
be.  It would 
seem to me that most all links that are rendered would have
*some* 
resource identifier behind them.

> Anyway, I strongly doubt we'll need to identify the
"resource/ 
> context" in which some other resource is being
rendered. The only use  
> case I can think of are relative links (as in ../foo
instead of /bar/ 
> foo), and those are more trouble than they're worth.
That's not to  
> say that the idea of a "rendering context"
isn't needed, just that  
> that context doesn't need to know about the
(pseudo-)resource in  
> which it's being used.

I think I agree here.  If I'm trying to render a resource,
I'm going to 
pass it off to the `get_url()` method (or whatever it's
called) and that 
will return a valid URL for the resource identifier I
specified.

This brings me to the `IResourceManager` interface.

First, from reading the TracDev/ContextRefactoring page, it
seems that 
in cmlenz's proposal, I would pass a resource identifier to

`self.env.get_resource_manager()` and I would get back an
the 
appropriate object that implements `IResourceManager`.  In
cboos's 
proposal, the `IResourceManager` interface is tied to the
resource 
itself, no?

Anyway, I mostly like the way cmlenz's proposal works. 
However, instead 
of returning a resource manager object, I would like to
simply call the 
corresponding function.  Ie:

self.env.resource.get_url(resource_identifier)

I don't really want to have to deal with passing around
resource manager 
objects.  Any reason why there shouldn't be just one manager
object 
attached to the environment?

Also, it seems to me that URLs returned from the
`IResourceManger` 
interface should exclude the scheme/hostname parts.  Please
correct me 
if my thinking is wrong.  It seems that if the URL returned
by the 
`IResourceManger` is just the path part, then it would make
things easier.

-John

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Trac Development" group.
To post to this group, send email to trac-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---