Re: Libole2.



time for me to get into the discussion: just managed to find
time to read my mail, between 2 sips of my cold vodka, on the
border of the swiming pool, while sun bathing ;)

Maciej Stachowiak <mjs@eazel.com> writes:

> Miguel, I'd really like it if you explained monikers to me in detail,
> or better yet, pointed me to some useful reading material. You and
> Mathieu keep saying how great they are, and how they are inherently
> more powerful than URIs, but I don't understand why.

"Inside OLE" is a good start (chapter 9 I think) but it is very badly 
written. if you can, try to fetch my old mail to the list on monikers
(I don't have it since I lost all my mail archives)


> Actually, this sounds _less_ powerful in some key ways. What if you
> have a data resource that can be handled by multiple different
> objects? What if I want to make the choice of which to use based on
> application-specific user preferences, or let the user change the
> choice of object to use at run time? Basically this breaks
> model-view-controller separation - you can't get a reference to the
> data resource itself, only to one particular object that thinks it
> knows how to handle it.

Could you give exampples of where users may want to set 
application-specific preferences ?

The whole idea about monikers is that users are supposed to setup
on a system-wide basis default applications supposed to handle
certain data resources.

However, if what you emphasize was really needed, this would be easy 
with monikers. This is only an implementation issue: we would need
to change the way monikers resolve (as oposed to COM way) so that
they take into account application specific needs.



> Obligatory whining about standards: Using ! in a URI like that is

That is a non-issue. The above exemple is simply there because we are 
so used to the broken microsoft behaviour.
This is simply an implementation issue.

> wrong; you shouldn't put anything in a URI that can't be resolved by
> the server. If you have a URI reference that needs additional
> client-side processing to resolve, probably the right thing to do is
> use a `#' separator. Unless monikers aren't supposed to be valid URIs,
> but merely things which look almost exactly like them - which I also
> think is bad.



> What if I have more than one program on my machine that can handle the
> spreadsheet? Maybe monikers solve this problem but it doesn't sound
> like it to me.

Users should decide on a system-wide default spredsheet application.
If they want to use another one, they should launch it themselves and
do the corresponding hacking.

Howvere, I got a beautiful solution for this case:

I am currently trying to get something like below to work:

OAFID:this-is-an-oaf-query#http://www.mathieu.org/myfile.gnumeric#Sheet1:Grap1

This would involve creating another kind of moniker: the OAF moniker (or name
it any other way: activation moniker would be okay too. don't flame me for this.)

The OAF moniker, if specified would allow you to do override the default
system-wide behaviour.

A complete design, as I discussed it with miguel and Dirk-Jan will folow soon
(before the end of the week)


regards,
Mathieu

-- 
Mathieu Lacage, mathieu@gnome.org
212 rue de tolbiac, 75013 Paris, FRANCE
http://www.advogato.org/person/mathieu




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]