Clipboard

[Svanberg Liss <lisss ydab se>]

Hello everybody.
I would like some feedback...

Some time ago ( a long time ago ) I begun writing on a gnome - clipboard (
which I called Fairytale ). Due some problems I had ( bad internet
connection ) this clipboard was developed independently of gnome.

I have been poundering if I should release it to the public, for about 2
months now...

But I havn't done this, because it's currently non-compilant with
bonobo/baboon. I have scanned through bonobo, and I think that there are not
really so  great differences after all - but I will need some help.

I need your opinions about my design of the clipboard, and I need your
opinions about how a number of things should be done.

I'll begin trying to give a brief description of how things are designed,
and then I'll continue with the incompabilitys against bonobo, and end the
letter with some questions about different solutions.

****** Current design *****
The clipboard is split into three major parts. Clipserver, Clipbook & User
interface.

Clipserver is a storage, and is allmost equivallent of baboon::Storage.
Every "clip" is stored as a "stream" object inside the clipserver.
The default clipserver stores things in memory.
Each "clip" inside the storage uses a "homemade" binary format.

The Clipbook is what you use as the clipboard. It exists because you should
connect to one clipboard, but you might use several different clipservers.
You can attach a filter ( using the same homecooked binary format ) to the
clipbook. Currently, this filter only can be used to "filter out" unwanted
clips, but my intention is that this filter should control a lot of more
things, like when a clip should be removed from a clipserver, or if a
particular kind of clip should be using a particular kind of clipserver.

The User interface, is not really part of the clipboard. It's an application
that is dedicated to control the clipbook, show the curent contents, setup
filters, DnD support, and so on. The ide'a is that existing clipboards
should be connected to the clipbook with the help of the user interface,
that is, clips in the native clipboard should be transferred to and from the
clipbook using the UI. The UI does not really need to be visible, but the
typical interface would be visible.
Note however that I have not written any code against the X-clipboard, since
I havn't found any good examples of how it works. Instead I've been playing
around with some DnD, but it's currently broken, and the code is ugly. :(

A few words about the "homecooked binary format"...
In short, this format allows you to fill a clip with various tagged data. A
little bit like a binary XML or something like that. ( Mabye I should have
used XML or pure MIME instead? Anyway, the format has been developed to be
able to deal with any kind of data, and is mainly used internally so I hope
that this isn't a problem. )
The ide'a is that the clipbook / clipserver doesn't really know or care
about what data you tag other data with, neither does it care about what
kind of data you store in it.
So you can store the entries "text/plain" and "this is a sample text" after
each other in a clip, or 0xf88ddf and "babayaga". The clipboard will not
care.
The filter will work because *you* tell the clipboard what kind of data you
wan't.
So, in the end, it boils down to the programmer that uses the clipboard,
that (s)he tags his/her clips with data that "everybody" has agreed to use.


**** Incompabilitys ****
Unless I'm stoned for using a nonstandard format internally, I think these
are the the main incompabilitys against bonobo:

The Clipserver::Stream is using a handle to a part of the stream. The effect
this have got is that you can insert / delete data *inside* an existing
"stream".
I'm not sure if every kind of bonobo::Stream can be extended this way, but
even if all bonobo::Streams can be handled this way, you'd still have to
"manually" move data in the bonobo::Stream in order to mimic this beaviour.
I don't consider this a gigantic problem. You can build the clip in memory
and send it over as it is to the storage. Hovever, if you later modify a
clip ( you do perhaps want it to belong to another category than your
filters currently think that it belongs to ), or if you wan't to store
gigantic amounts of data inside the clip, then this will be a problem.

When retreiving ( opening ) clips/streams from the Clipserver, you don't
pass a pathname, you pass a filter. Ideally the clipbook should have the
filter, and the clipserver/storage should just be a dumb container. I did it
this way, just because I wanted to speed things up.

**** What to do ****
Well, from what you have heard, what should I do...

What about this binary format? Does it sound OK?
Is there any point in letting a user open the clipboard with a text editor
and manually change the contents of it? Is it ok if you are required to use
the UI, or at least an editor that is connected through the UI?

Is the idea of tagging clips with various attributes ( that the user apps
may interpret anyway they want ) a good or bad one?

What about the "streams"? Should it be an error to place more data in the
clipboard than what fits into memory, even if you are storing the clip
against disk? Should it be an error trying to change the contents of an
existing clip?
If not, should I rewrite things so that I'm using bonobo::Stream as it is,
or should I use an stream object that inherites from bonobo, but wich adds
an "insert/shrink" method?

What about the storages? Should the clipbook be rewritten so that it scans
through the storage ( and do the filtering ), instead of letting the storage
do the job? Should I make the clipserver inherite from bonobo::Storage, add
a open_with_filter method as an optimization, but still allow pure
bonobo::Storages to be used with lower speed?

How should the Clipbook know when you are done with a clip.
( A clip is streamed, so you can hold it and alter it during a long time.
The clip belongs to the Clipserver. )
The clipbook should notify the UI when something in the clipboard changes.
Have I missed some callback functionality in the bonobo::Storage that allows
a client to be notifyed that something has changed in the storage?

How should the filter know where to store a certain clip? The problem is
again that the clips are streamed, so storing a clip is not an atomic
action. Should I run the filter against the clip each time something is
altered in it?
Should I interpret the bonobo::Storage::commit method so that the filter is
not run until I commit changes?

Should I publish it ASAP :-) , should I fix the compability problems first
and then publish it... :)

...or, should I "Throw the code away, as it's of no use anyway"....  :(
( And perhaps use a mailserver with filters as the gnome - clipboard? )


Cheers
// Liss