Re: [Envolution-devel] File Prefix's

[Mark C. <ma...@ma...>]

Very well said ak. I also agree about the absense of a Comments API and a
Ratings API. Both would be very useful to me. I also agree with the idea of
keeping api compliant downloads and just thrown together ones seperate. BTW,
as soon as the Reviews and Downloads module are api compliant and
templateable i have some templates for them. I have a great design for both
that could be the default layout on install. But of course users can make
them whatever they want, just thought a good default layout would be useful.
I know cleaning the code is the main priority right now and not features,
but just wanted to share a little bit of ideas.

I would almost call the code cleanup a rewrite. Why you ask? Because I feel
a lot of the code is a mess. Lots of hacks and quick fixes. I know I am
guilty myself of making these quick changes to maybe add a small feature to
a module or a change to the layout (full templates will fix this) that isnt
as efficient as it should be. Keep all the same features for now, but make
all core modules api compliant and take advantage of templates just like
they should. Take out modules that arent part of the core. If its not a core
module (and api compliant of course), we shouldnt include it in the standard
download.

I know PN is using the encompass code (Xanthia) for .726 and an even better
version for pn .8, so i think we can learn a lot from their changes they
made to our code. Looks like they are making it a little more effiecient and
have added a few options as well.

I have a lot of other ideas that I think will help with the code cleanup and
rewrite. I also have a lot of ideas on how to reorganize how changes are
made to made to different settings of modules, blocks, and encompass.
Basically making it easier to make the all the possible changes to a block
or module at one central point. Not all at the same screen, but not having
to back out of one module to get into another to make a change to the module
you were just at. LOL, not sure if you follow, but I will give some visual
examples later on.

Sorry, i know i jump around a lot with what i am talking about, but
hopefully you still understood the jist of what i was trying to say. I
talked about feature freezes, but then also added ideas about new features.
These of course can be used after the major cleanup is done.

-MACscr

----- Original Message -----
From: "Andrei Kivilev" <ak...@ho...>
To: <env...@li...>
Sent: Thursday, August 28, 2003 11:21 AM
Subject: RE: [Envolution-devel] File Prefix's


> Hi guys,
>
> First of all, this comment is not addressed to anyone in particular.
> Thus, it should not be taken as any sort of personal attack.
>
> Now, here is what I think about Envo and PN in their current (released)
> state. Both are platforms, and provide common features, like user
> management, multi-lingual interface and consistent themes. THAT IS IT!
> Oh yeah, and one "integrated" application on top of that, called News!
> So, IMHO, at the moment Envo = PN = News module. Most other differences
> are in presentation layer. BTW, how many Envo installations disable News
> module or at least do not make it the default one? And even this "core"
> module is NOT pnAPI (or any other API) compliant. On the other hand, 3rd
> party modules that are announced on Envo and PN sites most of the time
> claim to be 100% pnAPI (an exception might be pnHTML, but it is a
> completely different story). The reason is simple, PN (and its forks)
> had promised to support all modules that are pnAPI compliant. So, IMHO,
> it is of paramount importance for Envo to support pnAPI as it promised
> (if technically feasible, of course). On the other hand, I am all for
> "new" envAPI (or whatever we call it). It should take good ideas from
> pnAPI and add new features that will make creating modules for Envo
> easier and less time consuming. What I don't understand is why we still
> don't have Comments API or Ratings API or Notification API. I am sure
> most 3rd party developers would love to use these APIs in their own
> modules. After all, API is THE ONLY WAY for modules (blocks, or anything
> else) to interact with Envo. The same goes for Workflow. And Categories,
> and everything else. The question is, do we make a "bridge" between
> pnAPI and envAPI? I think not. This is not our job to integrate PN based
> modules with all the features Envo can provide. All we ever promised is
> that PN modules will not break because some of pn-something functions
> can't be found on an envo install. Furthermore, I would suggest we make
> all compatibility things into separate downloads, and make sure that
> users understand that by using them we can't guarantee that Envo install
> with these add-ons will perform as fast as the "clean" one. Think of it
> as Wine on Linux. You only use it when there is no alternative, period.
>
>
> Best Regards,
>
> ak
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Envolution-devel mailing list
> Env...@li...
> https://lists.sourceforge.net/lists/listinfo/envolution-devel