{#} Replies are directed back to [EMAIL PROTECTED]
{#} To reply to the author, write to David Remahl <[EMAIL PROTECTED]>
>> As I have not followed the Fire project very closely in the past, I have a
>> qeuestion about what your strategy is with plugins. The reason I ask, is
>> that I find the recently added file importing functions a bit misplaced. I
>> think that importing ICQ lists, should be placed in the ICQ service bundle,
>> ie through an update of the Service protocol. That would help us later
>> if/when we decide to make it up to the user which plugins are used (there
>> are 1 or two feature requests at sourceforge for this, I noticed).
>
> Except then the interaction between services and accounts gets a little
> fuzzy. Right now, there's a one-to-one correspondence, but we're hopefully
> going to break that paradigm at some future date. Besides, it's the
> application's job to manage your contacts, not each service's, which leads
> me to believe that they're better suited at the application level.
>
> Plus, it is quite conceivable (read: likely) that an imported file will
> contain buddies for more than one service.
Yes, if it is a Fire file that is imported. Files that can contain several
services should obviously be handled on the application level, but for
example Gerry's ICQ importion would be better off in the plugin imho.
>> This is not the only place where the core application could be further
>> slimmed, delegating responibility to the independent bundles.
>
> Remember that some things are better handled by the application itself.
> Some things can be delegated to a service bundle, yes, but the application
> will be better suited for some things, and able to handle some things that a
> bundle couldn't.
Absolutely.
> For example, if you want to be able to double-click on a .icq file and Fire
> open it and import the buddy, the application must be registered for that
> type of File, not the bundle. And Fire can't register itself to the OS to
> handle files of only certain types, dependent on what bundles it has loaded.
> That's a decision made when you build the app.
You have a point there. I didn't think of that...
>> Is this the direction you entend the project to go, or is there no intention
>> to get an architecture where the user selects services relevant to him/her?
>
> Something like that, but I, at least, have no clue how we're architecturally
> going to do it. Somebody said that you can delete a FireBundle to unload a
> service without any problems, but I haven't tried, so YMMV.
OK, but for now it is in accordance with what the aim of the application is
to integrate service-specific components into the core application on a
convenience basis?
/ david
{#} ----------------------------------------------------+[ fire ]+---
