Re: [PATCH 0/5] Add a standard module for accessing the layerindex

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Tuesday, 17 July 2018 10:56:14 PM CEST Mark Hatle wrote:
> > 2) I feel like the ;type= stuff is an unnecessary complication. Can we not 
> > just treat http URLs as being restapi and local:// (or something similarly 
> > simple) as being the local configuration? The plugins could simply have a 
> > function that returns True if it can handle the URL, as we do in bb.fetch2, 
> > and we take the first one that returns True or error out if none do.
> 
> Behind the scenes the issue is that I expect there to be different plugins that
> allow data manipulation in similar ways, but with different processing.  I was
> afraid of overriding the URI part, thus added the type field instead.
> 
> If we can come up with a proper format for this, then I think we could drop the
> typing..  but what I've come up with so far is that we need:
> 
> Cooker - data from the local cooker instance

local:// ?

> restapi-web - knowledge of how to load and parse layerindex-web data

http:// or https:// surely?

> restapi-file - a json formatted file with all of the data.. (Note: in this case,
> it can be one or more files, but everything has to be loaded together)

file:// ?

If the desire was to also allow downloading json files over http/https you could make
the decision after a quick query or simply check if the URL ends in .json.

> (the web and file stuff are co-mingled right now, maybe that is a mistake...
> they were put together since for 'offline' work, the web should be able to use a
> cached file...)
> 
> Looking at toaster, I could see the need for a 'database' way to store and load
> it... but I'm not sure that is a good longer term idea.

Toaster uses the Django ORM to access the database, so you wouldn't be
connecting to the database directly; you could make it accessible via a simple
scheme such as toaster://.

> > 5) I'd like to see the data classes (e.g. Recipe) have actual python 
> > properties on top of the getter functions, and the rest of the code should 
> > then use the properties. recipe.pn is a bit neater than recipe.get_pn() 
> > particularly as the former mirrors usage within the layer index code itself as 
> > well as tinfoil's TinfoilRecipeInfo (although TinfoilRecipeInfo doesn't 
> > actually use properties - it probably should - but the usage syntax is the key 
> > bit).
> 
> I'm not sure I understand.
> 
> You mean something like:
> 
> class Recipe(LayerIndexItem_LayerBranch):
>     ...
> 
>     self.pn = value
> 
> so you can do recipe.pn vs recipe.pn() or get_pn()?
> 
> The reason it's setup the way it is, is to preserve the data in the same format
> as the layerindex itself.  This allows someone to just dump the recipe.data
> directly, and everything stays in format.   Does python have a way to return
> processed data without it looking like a function call, i.e. with the ()?
> 
> Is this what __getattr()__ is for?

It's one way of implementing it, but the much cleaner way is to use python's 
built-in support for properties:

  https://www.programiz.com/python-programming/property

The underlying data storage doesn't have to change, your getter function can
still read the values in whatever way it wants to.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre