[dev] proposal: HUOS

[Anil Madhavapeddy]

Quoting Chuck Hagenbuch <chuck@horde.org>:
> 
> What would be stored:
> - a serialized representation of the object

Using whatever backend (wddx/native/other) I assume?

> - a unique id for that object
> - the owner of the object (a Horde username)
> - the time that object was last modified
> - the type of the object
> 

Sounds good ...

> - retrieve a specific object (optionally taking a username to make sure it
> matches the owner)
> 

It would take the unique id as the first argument?  In that
case optional validity checks for all the other fields in addition
to just owner would probably be needed.

For example, if you want to retrieve this object, but only if its 
not more than a month old (for some calendar related purpose perhaps,
which has expired).  Ok, far fetched example, but it's 3:00am :)

> - check if an object has been modified
> 
> - get all objects of a certain type belonging to a user (ie, all identities)
> 
> - get all objects belonging to a user
> 

Would something like Kronolith store its day (say, appointments) using
this, or does it just use ICAP?  In the former case, more flexible 
searches would also be needed on more than just the user field
right?  Alternatively, just retrieve a load of objects, and filter
one them using code, to avoid a bigger API, but this may involve
retrieving more objects than needed.

> a classloader api is a possibility, also, to allow storing classes in 
> a db - not that I'm convinced it's a great idea, but the flexibility 
> might be nice...)

Gulp, our company did something similar in the early days of PHP3 called
Omnisite - hugely flexible, but it was pretty hairy from a design
and maintainence POV, especially as the database classes start piling
up, and you forget what _this_ particular one does, etc...

> 
> One specific application would be to store an object id in the "server"
> preferences field for Horde users, instead of an index into the $servers[]
> array, to look up the servers for that user in the object store.
> 
> Does this seem well thought out to people? Does it solve a problem that
> needs solving?
>

It sounds great to me, and the problem of this kind of storage would 
be just be solved once and for all, and pretty flexibly too.
 
--
Anil Madhavapeddy, <anil@recoil.org>