> Rob, I came across this comment on /. regarding conversations between you
> (apparently) and a borderline-Plucker-user...
Yes I remember this gentleman that sent me this.
> >The other item is a one-click "sign up for this channel" functionality --
> >basically just a metadata file on our Web server containing URL, depth and
> >follow/nofollow directives, probably in XML. This requires some more work
> >on the desktop app and installer.
> I think it's a fantastic idea, if we extrapolate to the next obvious
> level. We could, once we put this structure in place, allow the same data
> to be downloaded from the Plucker website that David has redesigned so
> effectively for any channels listed. (i.e. users could simply
> point-and-load rather than having to configure the channel using the data
> on the website about each channel.) This could also eventually extend or
> replace the "Showcase" arena, which I'm ashamed to say I've never used.
This is the plan.
The current Desktop Showcase format (XML-kinda) will be deprecated, and a regular
plucker.ini
format used instead. If someone wants to put in the time, openurls.plkr.org can export
to
plucker.ini file format. David said he would have a look, but I am sure he would
welcome a
hand. Perhaps an XML file would be better eventually for a format instead of .ini, but
that
isn't near term, as it requires a python upgrade. And XML doesn't add much context
really,
since all the properties are "flat" because they need to be shared with commandline
parameters.
The Plucker Desktop code gets simpler to maintain because the same plucker.ini parsing
is used
both for the regular channels list, and the showcase. Moreover, the listctrl derived
class gets
recycled, since both will have the same columns.
For a file extension, Bill J. uses ".plkr" extension for the Plucker databases, and it
is
registered as a MIME type now. It is reasonable to pick a extension for a description
of the
channel contnet, like ".plkrdata" as you suggest, or similar
Using Plucker regular.ini files, the content provider can then just describe his
channel with
widgets for color depth etc, either online at plkr.org with web forms or with the
Desktop
software. Either avenue would export/generate a .ini file of the channel without
worrying about
what each key is called. Can then drop that .ini file on the server. Alternatively, a
joe-user
can make a list of channels to share or install elsewhere, by selecting the channels
in his
list and chooseing "Import/Export > Export selected channels" from menu (this is also
useful
for content that wants to be retrieved both at home and work, without resetting up all
the
channels again on the 2nd machine).
The current TODO mechanisms would allow a new channel to be add in such an ini file
via a
"Import/Export > Import channel" menu command.
The drag and drop of a file into the window would also look at extension, and if it
was the
say, .plkrdata file extension, instead of using that filename as a starting point, it
would
import it instead.
These are cross platform ways, and cross browser.
> but some form of interface (not necessarily graphical) is needed to simplify > this
>to the
> level of windows users or to automate it for the convenience of everyone else.
I agree.
> I will write a utility to parse the data and store it in the Plucker INI
> file. This would have three functions...
>
> 1. Installer - would update the Windows registry or the Linux
> /proc/sys/fs/binfmt_misc/register to recognize the unique extension
> (.plkrdata ? something else) so that it can be launched from any
> browser. Also asks for or confirms defaults for the non-site-specific data.
Yep.
> 2. Parser - Read one of these files, converting to ini format and storing
> the data in plucker.ini
This would actually also not cause problems when Plucker Desktop is running for adding
channels. Though the Desktop reads the .ini file, then maintains an internal state of
the keys,
and if modify then .ini file, then close Desktop, it will write the state keys.
However, it
will leave sections alone that it didn't have a key for in the internal state.
> 3. Creator (if needed) - given a channel name, convert that into the
> appropriate format (e.g. .plkrdata file). This could be as simple as
> grabbing the relevant fields from the relevant channel section of the INI
> file or it could require packaging of that up to a different format.
Probably not needed. Best just to use a single .ini format (less headaches).
The rundown for operation I guess then would be:
(1) Content provider has link to ".plkrdata" file on their website's HTML page.
(2) User clicks on link, and browser knows to do something with that plkrdata file, to
launch
the one-click utility include with an argument of the . .plkrdata file. (Is the part
that is
likely the most source of headache, dealing with the different possible browsers to
have them
set up right).
(3) The one-click utililty reads the lines of the .plkrdata file and transfers them to
the
plucker.ini. They should probably be sanity checked for at least being proper config
format, so
can't bring down the entire parser by a bad file. If using a wxWindows C++, this could
be
accomplished by a wxFileConig Read() and Write() to read into the .plkrdata file, but
then set
active config to plucker.ini and Write() it there. wxConfig would cough on the way in,
so it
wouldn't possibly write illegally formatted stuff to plucker.ini.
(3.5) Wesley had suggested to include the large and small icons, which I think is a
good idea.
These would be b64 encoded into the .plkrdata textfile. The timing of when to unzip
the b64 and
dump the icons into files ready for the parser is up in the air (do it on addition of
a new
channel from showcase/.plkrdata, or as part of process before starting a channel, or
put into
the parser to handle an icon as a text rendition (similar to how the default icon is
in the
sourcecode in Python)?
(4) If wxWindows C++, can _possibly_ do a quick IPC (Interprocess Communication) using
the
wxIPC class (which wraps the native OS's standard IPC mechanism) and if Plucker
Desktop is
running, then send a message to Plucker Desktop to reload the main frame's list of My
Plucker
Channels. If this step isn't done, I can see new users writing in saying "I added a
channel
with 1 click, but it isn't in the list--where is it?". The fallback if no IPC would be
a
"Refresh channels" menu command on Plucker Desktop, though that is suboptimal vs. an
automatic
refresh when needed. ("Refresh channels" menuitem would also be confusing, since it
doesn't
update channels). If IPC too difficult, can drop a key in the [PLUCKER_DESKTOP] to
tell to
refresh, and have to check every fixed interval if key=1, and if it is =1, then
refresh though
that drains processor power to keep checking. Just doing it on an event, would be
better, if
possible.
(5) An inform message tells if added successfully or not (with a checkbox to not show
again if
so desired). If wxWindows C++, can recycle that dialog class from the Plucker Desktop
source.
(6) Then one-click utility app terminates.
> So questions for the group...
>
> Is this a good idea? Would we use it ourselves? Would it help others?
I think it is a good idea, and would help others. Most of us are developers here, not
content
providers. Perhaps the content providers could ring in.
> If so, what subset of INI data should be used and what file format if not
> the INI format?
Support 'em all! ;-)
Might as well give the flexability. It is tough when parts of toolchains drop things.
Sounds fun though Fringe, if you are up to doing it. As Wesley mentioned, this has
been
mentioned before, but needs someone to put it together.
Best wishes,
Robert
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
