Now a full reply :-) On Tue, Sep 18, 2012 at 2:15 AM, Michael Blumenkrantz <michael.blumenkra...@gmail.com> wrote: > > * EDBus as a namespace is really annoying to type and should be Edbus by > the EFL coding standards anyway. this applies to headers, types, and > anything else which uses improper capitalization
As said in previous email, in my interpretation it does meet the standard. But we can change that with a simple sed. > * EDBus_Proxy should be Edbus_Interface since anyone who knows dbus code > and sees proxy will go WTF since that's not even a dbus keyword. this also > applies to the entire edbus_proxy namespace. it may be the case that it's > proxying an interface, but there's no need to add confusing unrelated > terminology here actually DBus guys do use that term. http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html http://qt-project.org/doc/qt-4.8/QtDBus.html (calls it interface, but explains saying "Proxy for interfaces on remote objects") http://www.valadoc.org/gio-2.0/GLib.DBusProxy.html I've choose to NOT name it interface on purpose to not be confused with the server interfaces (when you expose an interface). Originally I've called it "Binding" but it was too long and too uncommon so people asked me to call it "proxy" due the above reasons. > * edbus_connection_cb_free namespace should be edbus_connection_free_cb my bad, I recalled from mind that elm used that, but I was wrong :-P (just noticed it now) > * EDBUS_CONNECTION_EVENT_NAME_OWNER_CHANGED is commented out...I assume > this will be usable later? maybe, need to evaluate. > * imo all the random #defines which share namespaces should be enums ok > * if the point was to get away from libdbus, why does this still use the > exact same bad methodology as libdbus, such as EDBus_Message_Iter? why do > we not have serialization from/to native EFL types, or at least something > like serializing to Eina_Value? Long story short, it's to construct large messages interactively without much overhead. If you're reading/writing to/from wire you can do zero-copy as strings and similar are \0 terminated. Then you do not allocate it, just point to there and no need to intermediate copy. Also simpler to construct. That said, we'll introduce some helper to convert to-from Eina_Value for an Message and Iterator. We'll need this once we introduce the FDO Properties and ObjectManager helpers. These are higher level and likely people will use that instead, and to do so we'll keep the properties as Eina_Value. Again for performance, the user will have 2 ways of doing the properties: 1 - user will do async methods to get/set properties, handling conversion (faster but more cumbersome) 2 - user will call monitor() on an object/interface (proxy) and it will store properties locally based on PropertyChanged. Then get is now synchronous (local) and uses Eina_Value. Set is still asynchronous, but will use Eina_Value as well. ObjectManager is the same, complements the above picture. Once you monitor it will create the proxies for you and monitor their properties... then everything is local and easy to manage. > * EDBUS_ARGS looks neat, bonus points for this demarchi++ :-) > * have you considered adding an error param to message callbacks to > simplify checking for errors every time? message always had the error (it could be an error message), but we were duplicating this with the DBusError before. Now it's always in the message... meaning you always have the message, so indeed it's simplified. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
